Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

June 2017

1 participants
60 discussions

ffmpeg-devel.log.20170619
by burek 20 Jun '17

20 Jun '17

[00:21:55 CEST] <J_Darnley> BBB: thank you for your incredible efforts [00:22:41 CEST] <J_Darnley> I will do my best to that patch you made. [00:23:25 CEST] <J_Darnley> *to check [00:23:48 CEST] <J_Darnley> Otherwise I will see if I an make wmv1 always use the C [00:24:40 CEST] <J_Darnley> Failing that I will leave the new code unused with -idct simple [00:25:23 CEST] <atomnuker> jkqxz: is the hardware vp9 encoder on newer intel systems realtime? so finally there's a way to encode vp9 in real time? [00:27:12 CEST] <atomnuker> (I think the only way that was doable currently was with one of those old very clockable intels clocked at 7.5Ghz cooled with liquid nitrogen) [00:27:13 CEST] <jkqxz> It can 4K60. Is that realtime enough for you? [00:27:28 CEST] <atomnuker> whoa [00:27:28 CEST] <BBB> how good is the quality? [00:27:38 CEST] <BBB> I can make you a realtime encoder in a few minutes, it just will suck [00:27:51 CEST] <BBB> aka bitstream writer" [00:28:07 CEST] <jkqxz> Not completely terrible - better than the QuickSync H.264 encoder. I've never investigated much beyond that, though. [00:28:16 CEST] <BBB> J_Darnley: happy to make it work :) I hope this was the last of it, though [00:30:37 CEST] <J_Darnley> It was the last from fate [00:33:53 CEST] <kierank> jkqxz: i thought 4kp30 max? [00:34:07 CEST] <jkqxz> atomnuker: It maintains about 70fps at 4K on my 7500U. [00:34:31 CEST] <kierank> interesting [00:34:39 CEST] <nevcairiel> vpx has a re altime mode, no clue how terrible the quality output is though [00:34:54 CEST] <jkqxz> If someone wants streams to analyse the quality of I can easily make them. [00:35:17 CEST] <atomnuker> nevcairiel: the realtime mode just disables certain bitstream features AFAIK [00:36:16 CEST] <JEEB> heh [01:11:47 CEST] <TMM> Is it possible to submit patches to this page? https://www.ffmpeg.org/developer.html The link to the Signed-Off-By explanation points to nowhere now, it should point to https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign… [01:15:31 CEST] <durandal_1707> no need [01:16:28 CEST] <TMM> ok [01:18:03 CEST] <atomnuker> TMM: if you want to submit a patch to the website just git clone https://git.ffmpeg.org/ffmpeg-web and submit a patch to ffmpeg-devel as usual [01:19:05 CEST] <TMM> atomnuker, I'll do that, thanks [01:20:25 CEST] <durandal_1707> get re other codecs in mean time? [01:20:42 CEST] <TMM> me? [01:20:59 CEST] <durandal_1707> who else [01:21:10 CEST] <durandal_1707> only you left [01:21:44 CEST] <kierank> lol [01:21:52 CEST] <kierank> durandal_1707: you are becoming keiler2 [01:22:03 CEST] <atomnuker> !42!# [01:22:06 CEST] <durandal_1707> who? [01:22:20 CEST] <TMM> durandal_1707, well, I'm going to port some of the scummvm enhancements to bink to ffmpeg, and implement sprite support for truemotion1 [01:22:55 CEST] <durandal_1707> huh, sprite? [01:22:57 CEST] <TMM> durandal_1707, We're adding more FMV games to scummvm, so I imagine more codecs will be coming, there's a lot of em in that space [01:23:19 CEST] <TMM> yeah, truemotion1 has a 'sprite mode' that's currently unknown [01:23:35 CEST] <TMM> it's used by a lot of the fmvs at the time, like the star trek fmv games [01:24:22 CEST] <durandal_1707> oh, what about nongame codecs? [01:25:23 CEST] <TMM> not really my area of interest, but if you have a suggestion for something that's actually used I can maybe put it on the list? [01:26:24 CEST] <TMM> surely other people are reverse engineering video codecs? [01:27:05 CEST] <durandal_1707> mostly kierank expertize, ask him for help [01:27:13 CEST] <kierank> lol [01:27:31 CEST] <TMM> I'm... confused [01:27:43 CEST] <kierank> there are not that many video codecs left to RE [01:28:24 CEST] <durandal_1707> there are many left, but dead [01:28:42 CEST] <TMM> well, if they are used in games I'll run across them eventually I guess? [01:29:37 CEST] <durandal_1707> games are very special, there is bunch of audio only formats [01:30:05 CEST] <TMM> yeah, scummvm has support for quite a few somewhat obscure audio formats [01:30:20 CEST] <durandal_1707> for video there are bunch of bink variants [01:30:34 CEST] <TMM> I intend to port all of them to ffmpeg, and then add a libavformat/libavcodec compatibility layer in scummvm to use the codesc from ffmpeg directly [01:30:49 CEST] <durandal_1707> omg [01:30:54 CEST] <TMM> scummvm doesn't want to depend on libavcodec/libavformat directly [01:30:58 CEST] <durandal_1707> you cant be serious [01:31:55 CEST] <TMM> *shrug* it's the best way I know of how to get the knowledge of scummvm into a more generic form for others [01:32:25 CEST] <JEEB> some people just have weird ideas about FFmpeg (and if you've never touched the APIs the libs can feel scary) [01:32:28 CEST] <TMM> I'd rather not have this duplicated and the internal apis for those things are pretty simple [01:32:39 CEST] <JEEB> although during the last N years the APIs have improved [01:32:56 CEST] <TMM> maybe, but scummvm tries to run on weird ass hardware [01:33:26 CEST] <JEEB> if you've seen the FATE suite there's plenty of stuff there, too :) [01:33:39 CEST] <TMM> I doubt I can get ffmpeg interested in an officially supporting os/2 [01:33:46 CEST] <TMM> or dreamcast [01:33:54 CEST] <JEEB> I thought the koreans were posting patches wrt OS/2 [01:34:08 CEST] <JEEB> dreamcast I'm not sure if it needs special stuff if the toolchain is OK? [01:34:22 CEST] <jamrial> afaik ffmpeg used to compile on sh4 targets [01:34:32 CEST] Action: JEEB built FFmpeg for PSP some time ago, which is an older MIPS thing [01:34:33 CEST] <jamrial> years ago, though. probably not anymore [01:34:35 CEST] <TMM> I don't know either, but the scummvm project is super paranoid about portability [01:34:55 CEST] <TMM> I really doubt I'll ever get enough people convinced to add libavcodec/libavformat as an external dependency [01:35:49 CEST] <TMM> I don't think it'll really matter, I just want to be able to share the interesting codec and demuxer bits between the two projects [01:36:39 CEST] <TMM> The way I see it, what scummvm does for old games ffmpeg does more generalized for av formats. I think it's important to preserve both in its most useful form [01:36:51 CEST] <TMM> for games that's I think in scummvm, for av formats that's ffmpeg [01:36:56 CEST] <durandal_1707> does your mve patches allows to play super mario sample from trac? [01:37:02 CEST] <TMM> durandal_1707, yes [01:37:26 CEST] <TMM> durandal_1707, that's a format 0x10 movie, that's supported with my patchset [01:37:35 CEST] <durandal_1707> great [01:38:38 CEST] <durandal_1707> so scummvm have support for such games that use this coding? [01:38:40 CEST] <TMM> the star trek trailer seems to use another unknown opcode, but the movie plays fine [01:38:56 CEST] <TMM> I'll probably look into that eventually [01:39:57 CEST] <TMM> durandal_1707, we're currently adding support for a game called "Kingdom: The far reaches" it uses both the 0x06 and 0x10 frame formats. Although, as it turns out, it only uses the 0x10 frame format for the Interplay logo. That was a little disappointing. But at least we can now maybe add support for mario teaches typing :P [01:43:45 CEST] <TMM> https://trac.ffmpeg.org/ticket/5401 <-- this also plays now [01:44:45 CEST] <TMM> https://trac.ffmpeg.org/ticket/4740 <-- this too [01:45:36 CEST] <TMM> should I comment on the trac thing? Or just wait to see if this gets merged? [01:45:54 CEST] <Shiz> TMM: you may be able to get support in as sh4 is an upstream linux arch too [01:46:01 CEST] <Shiz> that should lay some basics for dreamcast support [01:48:35 CEST] <TMM> maybe, if I can get it to build everyhwere... I'll have to ply some developers with beer I think. Actually using libavcodec is going to meet with quite some resistance [01:50:54 CEST] <jamrial> TMM: wait for the patches to be commited. then those tickets can be closed [02:01:39 CEST] <cone-289> ffmpeg 03James Almer 07master:3c5a53cdfa09: avformat/oggenc: add ogg_init() and ogg_free() [03:46:51 CEST] <cone-289> ffmpeg 03James Almer 07master:e229df9478b2: x86/aacpsdsp: add ff_ps_hybrid_synthesis_deint_{sse,sse4} [03:46:52 CEST] <cone-289> ffmpeg 03James Almer 07master:8bb59e6742ee: x86/aacpsdsp: add ff_ps_hybrid_analysis_ileave_sse [03:48:47 CEST] <jamrial> single threading decoding of HE-AACv2 went from 533x real time to 548x real time on my haswell i5 with those two patches :p [03:49:44 CEST] <jamrial> kierank: ^ i think think you were interested in aacps performance some time ago [03:49:55 CEST] <jamrial> although now with opus maybe not anymore [03:55:12 CEST] <kierank> jamrial: no not me afaik [03:58:06 CEST] <rcombs> nice [04:36:22 CEST] <cone-289> ffmpeg 03Steven Liu 07master:3996ae930256: avformat/hlsenc: donnot show duplicate segment warning at byterange mode [09:31:18 CEST] <mateo`> I'm working on fixing the checkasm_checked_call on aarch64, it makes the new checkasm float_dsp test fails (but also the future sbrdsp tests that i'd like to add) [09:32:04 CEST] <mateo`> currently, functions that return a float always return 0 [10:53:46 CEST] <cone-698> ffmpeg 03Nicolas George 07master:d790f18ac0c3: lavfi: print the error message when threading init fails. [11:15:19 CEST] <Guest69427> Hi, I'm using ffprobe to get the number of frames "nb_frames". Then I use it as input to ffmpegs select filter. Is it possible to get "nb_frames" without using ffprobe, maybe as an input parameter to select? Or is it possible to pipe the stream from ffprobe directly into ffmpeg so I don't need to download the file twice? [11:16:35 CEST] <nevcairiel> to count the frames you first need to read the entire file, so if you need this information before actually processing the file, reading it twice seems unavoidable [11:17:15 CEST] <Guest69427> Ok, I see [11:27:23 CEST] <Guest69427> @nevcairiel Reading the file is not the problem but downloading it twice is. Does ffprobe and ffmpeg share cache or something like that? [11:46:55 CEST] <wm4> I don't think ffprobe normally actually counts the number of frames [11:47:00 CEST] <wm4> so this info is likely very unreliable [11:55:25 CEST] <JEEB> ffprobe -show_frames I think decodes them all? [11:55:54 CEST] <JEEB> Guest69427: no. you'd have to either use the API or just handling the transfer of stuff separately [11:57:35 CEST] <thebombzen> Guest69427: by the way, #ffmpeg is the ffmpeg help channel and #ffmpeg-devel is the channel about working on ffmpeg itself, just for future reference [13:44:24 CEST] <J_Darnley> Hello BBB. Could I ask you for a brief summary of what the last patch you gave me does? [13:44:50 CEST] <BBB> disable unquantize shortcuts based on end-of-block positions for wmv1 [13:45:01 CEST] <J_Darnley> Ah [13:45:05 CEST] <BBB> because the scantable used in the unquantized scantable does not match the one used in wmv1 [13:45:29 CEST] <BBB> I dont know 100% for sure why, it may be because h263_unquantize_intra uses the inter scantable (????????) [13:45:37 CEST] <BBB> and I believe wmv1 has a specific intra scantable [13:45:42 CEST] <BBB> but I dont know 100% for sure [13:46:29 CEST] <BBB> regardless, the bug was in unquantize not dequantizing some coefs, and the reason was that the end-of-block position not making sense, so this works around it [13:46:42 CEST] <J_Darnley> Okay, I will write a note in the commit message [13:47:07 CEST] <J_Darnley> Or since this is a 2 line change, a long essay [13:51:44 CEST] <BBB> hehehe [13:51:56 CEST] <BBB> someone (michaelni) may actually have ideas on better fixes for this [13:52:04 CEST] <BBB> my gal isnt so much to provide ideal fixes, but rather to pinpoint the bug [13:52:09 CEST] <BBB> theres many ways to fix bugs like this [13:52:19 CEST] <BBB> and Im fine if michaelni chooses to fix it differently or re-do the fix later on [13:52:29 CEST] <BBB> (or anyone else, for that matter) [13:52:36 CEST] <BBB> gal->goal [14:13:12 CEST] <cone-329> ffmpeg 03Paul B Mahol 07master:ca5cf84655f3: avfilter: add superequalizer filter [14:13:12 CEST] <cone-329> ffmpeg 03Paul B Mahol 07master:b9d0a5fc215f: avfilter: add roberts cross operator [14:19:21 CEST] <J_Darnley> BBB: sorry to bug you again but do you know how changing the IDCT permutation lead to this being revealed? [14:20:54 CEST] <BBB> the mmx implementation for unquantize dequants in 4x1 blocks [14:21:33 CEST] <BBB> so the permutation causes the position of the non-zero-by-unquantized coef to change [14:21:46 CEST] <BBB> the bug was there before and may or may not have caused quality degradations in wmv1 encoding [14:21:52 CEST] <BBB> but nobody encodes wmv1 so nobody cares [14:22:09 CEST] <JEEB> ayup [14:47:17 CEST] <TMM> What's the preferred way of updating a patch on the mailing list? I was thinking of replying to my original patch with the new version? [14:47:56 CEST] <atomnuker> I prefer a new post with prefix [PATCH v2] [14:48:20 CEST] <TMM> should i repost my entire series then? [14:48:43 CEST] <atomnuker> no, just what you changed with --subject-prefix="PATCH v2" [14:49:05 CEST] <TMM> OK, I'll see if I get some more reviews and repost the patches that changed then [14:49:16 CEST] <BBB> michaelni: does ffmpeg have a way of doing encoder/decoder reconstruction buffer matching? (like dump-yuv in x264) [14:49:17 CEST] <atomnuker> also use git send-email if you can because downloading attachments to view new patches is annoying [14:49:23 CEST] <BBB> michaelni: that might be incredibly helpful as a fate test [14:49:55 CEST] <atomnuker> we have vsynth tests... [14:50:04 CEST] <BBB> they just measure psnr [14:50:19 CEST] <BBB> they dont measure that the encoder/decoder representations match [14:50:45 CEST] <BBB> imagine that you have in.yuv [14:50:53 CEST] <BBB> and we do ffmpeg -i in.yuv -c:v blabla out.avi [14:51:01 CEST] <BBB> ffmpeg -i out.avi -f rawvideo out-yuv [14:51:06 CEST] <BBB> measure_psnr in.yuv out.yuv [14:51:07 CEST] <atomnuker> yes, I know what you mean [14:51:12 CEST] <BBB> ok [14:51:40 CEST] <BBB> (for those who dont: I want ffmpeg -i in.yuv -dumpyuv dump.yuv out.avi and then assert that dump.yuv and out.yuv are identical) [14:51:46 CEST] <atomnuker> what's wrong with testing encoders and decoders separately? [14:51:54 CEST] <BBB> that should still be done [14:52:13 CEST] <BBB> but I want to ensure that the encoder representation of the decoder state (reference frame reconstruction etc.) is correct [14:52:16 CEST] <BBB> I believe right now its not [14:52:30 CEST] <BBB> at least for wmv1 [14:54:46 CEST] <michaelni> BBB, there was CODEC_FLAG2_MEMC_ONLY, it was removed by a merge (e37f161e66e042d6c2c7470c4d9881df9427fc4a) [14:55:42 CEST] <BBB> Im not sure Im familiar with that flag :( [14:55:44 CEST] <BBB> what did it do? [14:56:00 CEST] <michaelni> what you asked for [14:56:27 CEST] <michaelni> it wasnt supported by most codecs though [14:57:08 CEST] <BBB> Im not sure what it does based on the description I find online [14:59:27 CEST] <BBB> a literal dumpyuv option would not need per-codec support, right? [14:59:52 CEST] <BBB> I mean, for mpegvideo, it would literally be done at the end of the slice coding loop [15:00:13 CEST] <BBB> that wouldnt enable it for libx264/vpx, but at least itd work for all mpegvideo-style codecs [15:00:17 CEST] <atomnuker> the thing is what happens if the encoder's quality changes? [15:00:27 CEST] <BBB> wdym? [15:00:46 CEST] <atomnuker> well, the reconstruction would be different [15:00:55 CEST] <BBB> why [15:01:02 CEST] <BBB> or: different from what? [15:01:11 CEST] <atomnuker> from the previous value it had [15:01:15 CEST] <BBB> thats fine [15:01:21 CEST] <BBB> but the decoder recon should change along with it [15:01:25 CEST] <BBB> we dont take a md5 of the yuv [15:01:31 CEST] <BBB> we just ensure decoder/encoder md5 of the yuv match [15:01:38 CEST] <BBB> we dont care what their value is [15:01:42 CEST] <BBB> as long as it matches [15:01:50 CEST] <BBB> the existing psnr check will make sure that quality is fine [15:02:00 CEST] <BBB> (ignoring whether psnr is a good quality metric) [15:02:17 CEST] <atomnuker> I don't get it, they can't ever match unless the codec is lossless [15:02:26 CEST] <BBB> they have to match [15:02:30 CEST] <BBB> read x264 --dumpyuv [15:02:33 CEST] <atomnuker> you're talking about the decoder's output? [15:02:35 CEST] <BBB> if they dont match, the encoder is buggy [15:02:36 CEST] <BBB> yes [15:02:44 CEST] <BBB> run it [15:03:21 CEST] <BBB> x264 -i somefile dumpyuv bla1.yuv -crf 40 out.x264 && ffmpeg -i out.x264 bla2.yuv && assert(!memcmp(bla1.yuv, bla2.yuv)) [15:03:32 CEST] <BBB> run that, youll see it matches [15:03:38 CEST] <BBB> it _has_ to match, regardless of options [15:03:42 CEST] <BBB> if it doesnt match, your encoder is broken [15:04:17 CEST] <BBB> how can x264 do motion search if it doesnt know what the reference frames reconstruction in the decoder looks like? [15:04:23 CEST] <BBB> it would never be r/d optimal [15:04:42 CEST] <atomnuker> oh ffs, be more specific damnit [15:04:50 CEST] <BBB> I dont understand what you mean [15:05:10 CEST] <BBB> x264 (or ffmpeg, or whatever) will encode blocks with a particular reconstruction based on prediction and coefficients [15:05:37 CEST] <BBB> this reconstruction is defined, it has a particular expected form and that is guaranteed to be identical for a given implementation of the decoder [15:05:38 CEST] <atomnuker> I thought you meant encoder -> packet -> decoder, not encoder -> packet AND ref out -> decoder, etc [15:06:01 CEST] <atomnuker> I've never used x264's cli tool so I didn't what what its option was [15:06:07 CEST] <BBB> ah [15:06:19 CEST] <BBB> dump-yuv is amazing for debugging [15:06:28 CEST] <BBB> (if youre working on x264 internals and butchering random crap) [15:06:41 CEST] <BBB> libvpx has a similar feature [15:06:53 CEST] <TMM> atomnuker, on the new patchset I did use git send-email, the RFC patch was all kinds of wrong, sorry about that. [15:07:32 CEST] <BBB> (--test-decode=) [15:30:53 CEST] <BBB> regarding the vaapi patches, does that work on hw decoders? [15:31:49 CEST] <jkqxz> Does what work on hw decoders? [15:33:29 CEST] <BBB> show-existing-frame [15:34:17 CEST] <jkqxz> Why wouldn't it? It has to be there in the decoded frames to be used for reference. [15:34:29 CEST] <BBB> I dont think all hw decoders support it [15:34:31 CEST] <jkqxz> I admit I've only tried the VAAPI hwaccel, though. [15:34:36 CEST] <jkqxz> What decoders don't? [15:34:59 CEST] <BBB> what kind of cell phone do you have? [15:35:02 CEST] <BBB> and your friends [15:38:02 CEST] <BBB> jkqxz: serious question :) [15:40:28 CEST] <jkqxz> SnapDragon 430. I can't tell whether that should have it or not. [15:41:21 CEST] <jkqxz> This mode isn't enabled by default, so I'm not sure how much I care about incomplete hardware implementations which can't cope with it. [15:41:55 CEST] <BBB> out-of-order frames/alt-ref frames? [15:42:13 CEST] <BBB> Ive seen the problem in snapdragon 820, I believe it may exist (from what Ive heard) in others also [15:42:47 CEST] <jkqxz> What is the observed behaviour? The reordered frames just never get shown? [15:43:15 CEST] <BBB> they are corrupted [15:52:52 CEST] <jkqxz> Hmph. Supposing it does fail on some devices, what should I do about it? [15:55:27 CEST] <BBB> jkqxz: now thats a very good question. You could use overlay frames like libvpx does& you could disable alt-ref frames altogether. or just show a warning and use show-existing-frames anyway [16:02:25 CEST] <BBB> if you dont think any of this matters, you could also ignore it [16:04:36 CEST] <jkqxz> That means encoding an all-skip frame referring to the non-shown frame encoded earlier? [16:07:30 CEST] <BBB> thats an overlay frame, yes [16:07:33 CEST] <BBB> its quite complex TBH [16:07:46 CEST] <BBB> which is why I said if you want ot ignore this, I get it and its fine [16:09:36 CEST] <jkqxz> Yeah. Feeding the frame into the hardware encoder again will probably generate something subtly different (and slow everything down signficantly), while making it in software would be a very non-fun exercise in the entropy coding (especially because it would be necessary to decode quite a bit of the rest of the stream coming from hardware to do that). [16:14:29 CEST] <jkqxz> Probably also messes with RC. show-existing-frame is very nice there because it's just one byte. [16:20:13 CEST] <BBB> I agree [16:20:15 CEST] <BBB> ok, fine then [16:20:28 CEST] <BBB> just saying youll probably get a bug report at some point about it [17:35:23 CEST] <atomnuker> BBB: what happened with the gsoc to implement vmaf? [17:44:28 CEST] <tdjones> atomnuker: I'm not sure I understand what you mean by determining the optimum residue classbook in the vorbis encoder. The classbook is defined in the header of the stream, before any audio is analyzed [17:46:38 CEST] <BBB> atomnuker: wdym? yours? or mine (ashish)? [17:47:00 CEST] <BBB> mine is working on it as we speak, and has some working code for part of the project [17:52:17 CEST] <atomnuker> cool [17:52:51 CEST] <atomnuker> tdjones: the header currently goes in extradata which is prepended onto the packet and is static, so you'll have to modify that [17:53:03 CEST] <atomnuker> (its a weird design choice) [17:55:45 CEST] <cone-329> ffmpeg 03Michael Niedermayer 07master:f670c13f1399: avcodec: Rename ff_mpv_decode_mb() to ff_mpv_reconstruct_mb [17:55:46 CEST] <cone-329> ffmpeg 03Michael Niedermayer 07master:cf7edbd6c5d4: avcodec/aacdec_fixed: Check s for being too small [17:55:47 CEST] <cone-329> ffmpeg 03Michael Niedermayer 07master:5f89747086af: avcodec/wavpack: Fix undefined integer negation [18:00:37 CEST] <atomnuker> tdjones: give me a moment, I'll give you a patch which does that [18:01:04 CEST] <atomnuker> (this is absoultely horrible, what idiot thought it was a good idea to put the header in the extradata) [18:16:19 CEST] <atomnuker> holy fucking shit... [18:19:02 CEST] <tdjones> All headers in vorbis are defined at the beginning of the stream, not per packet. I'm curious what harm is done putting them in extradata for the context [18:19:38 CEST] <atomnuker> this is fucked up [18:20:03 CEST] <cone-329> ffmpeg 03Paul B Mahol 07master:2820c9dfaa1f: avfilter/af_superequalizer: fix out of array access [18:20:04 CEST] <cone-329> ffmpeg 03Paul B Mahol 07master:53624d62d9a3: avfilter/af_superequalizer: improve description [18:20:54 CEST] <atomnuker> tdjones: do multiple modes work yet? [18:21:57 CEST] <atomnuker> so in vorbis, you predefine everything you plan to use at the header in terms of modes and you switch between them at runtime [18:22:24 CEST] <atomnuker> ...without any knowledge what input you'll get... [18:22:51 CEST] <atomnuker> this is completely backwards [18:23:06 CEST] <tdjones> yes, I have multiple modes and windows set up correctly [18:23:31 CEST] <tdjones> And, yes practically everything is defined at the beginning of the file [18:26:44 CEST] <tdjones> The offside is that each residue adds more memory the decoder must store when going through the stream [18:27:53 CEST] <tdjones> I'm not sure how much increase in quality would actually come from switching mappings for anything other than subwoofer channels [18:34:00 CEST] <TD-Linux> atomnuker, yes, in practice they are fixed per encoder version [18:35:03 CEST] <TD-Linux> the idea was room for future encoder improvements, however in retrospect it was considered a bad idea, hence why opus went in the opposite direction [18:35:49 CEST] <cone-329> ffmpeg 03Paul B Mahol 07master:1a4236e025a8: avfilter/af_superequalizer: stop leaking s->out frame [18:40:44 CEST] <atomnuker> tdjones: bind the number of passes (currently 8) in for (pass = 0; pass < 8; pass++) { to avctx->compression_level and set it to 8 as default again (using AVCodecDefault like opusenc) [18:44:59 CEST] <atomnuker> after that adjust the encoder to create 2 residues and thus 4 mappings (1 per each frame type, so 2 since you have 1 long and 1 short type x 2 = 4) [18:47:20 CEST] <atomnuker> after that write a search_for_residues() function which calls residue_encode with different mappings in the main function and measures distortion and bit cost [18:48:09 CEST] <atomnuker> (use euclidian distance e.g. dist += (x[i] - y[i])^2 and then take the sqrtf of the distortion) [18:48:22 CEST] <tdjones> atomnuker: That should work [18:48:34 CEST] <atomnuker> then once you have distortion and bit cost you can do RDO [19:02:33 CEST] <cone-329> ffmpeg 03Paul B Mahol 07master:ef178f630f79: avfilter/af_stereotools: add 2 more modes [19:30:02 CEST] <cone-329> ffmpeg 03Paul B Mahol 07master:c7a2a379fd05: doc/filters: fix typo [20:01:59 CEST] <BBB> J_Darnley: do you know how to add the permutated quant table to mdec? [20:02:39 CEST] <BBB> J_Darnley: I can write that for you if you dont know how to do it [20:07:27 CEST] <BBB> J_Darnley: other than the few comments, I think the patch series is pretty cool and I really like how simple no longer means c" [20:07:34 CEST] <BBB> thats a massive improvement IMHO [20:09:48 CEST] <KevinM> I have a few patches outstanding from the past week or two. They're relatively minor, in my opinion. Is there any time after which it's acceptable to ping them? [20:10:11 CEST] <JEEB> 21 [20:10:43 CEST] <kevmark> Three weeks? Gotcha. [20:11:01 CEST] <JEEB> no [20:11:04 CEST] <JEEB> that was me typoing [20:11:05 CEST] <JEEB> sorry [20:11:14 CEST] <JEEB> anyways, it's OK to ping within 5-7 days [20:11:35 CEST] <kevmark> Okay, thanks. [20:11:36 CEST] <JEEB> although sometimes nobody who knows enough about the subject is around [20:11:45 CEST] <BBB> then just push IMO [20:11:47 CEST] <JEEB> which is why some even simple patches can lie around on the ML [20:11:55 CEST] <BBB> esp. if theyre trivial [20:12:10 CEST] <J_Darnley> BBB: I will probably manage [20:12:14 CEST] <kevmark> BBB, I don't have push access as far as I know [20:12:22 CEST] <kevmark> Oh, sorry, wrong convo [20:13:44 CEST] <kevmark> JEEB, Thanks, makes sense. I believe Michael is familiar with the scale filter that I've been working on so I was just waiting for him to get around to that again. I've had a few patches for that filter accepted from him already. [20:13:45 CEST] <BBB> kevmark: that one comment was for you :) [20:14:04 CEST] <BBB> kevmark: didnt I close a bug for you a few days ago? [20:14:06 CEST] <BBB> anyway [20:14:08 CEST] <kevmark> BBB, is there an application process I need to go through to have push access? [20:14:16 CEST] <BBB> kevmark: ask michael :-p [20:14:20 CEST] <BBB> or really, ask on the m/l [20:14:28 CEST] <kevmark> I believe it was this? https://trac.ffmpeg.org/ticket/5392 [20:14:35 CEST] <BBB> but youd still need to get approval to push patches, you can just push approved patches yourself [20:14:43 CEST] <BBB> yes [20:15:07 CEST] <kevmark> Michael has set me up with a developer trac account (so I can close bugs) but I'm guessing that's separate from the repo [20:16:02 CEST] <BBB> indeed [20:19:17 CEST] <kevmark> I'll post to the m/l regarding push access. Thanks BBB, JEEB [20:19:18 CEST] <BBB> reimar is alive! \o/ [20:19:27 CEST] <BBB> kevmark: sgtm [20:19:43 CEST] <BBB> kevmark: if you want quick patch push, poke me with a link to the ffmpeg-devel archives patch [20:21:45 CEST] <kevmark> BBB, Doc change that has a LGTM https://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/212271.html [20:25:23 CEST] <kevmark> BBB, Michael requested a change to the previous patch and this is the updated one although hasn't been specifically given the ok on its own https://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/212396.html [20:26:10 CEST] <cone-329> ffmpeg 03Kevin Mark 07master:5aea18cbd882: doc/filters: Correct scale doc regarding w/h <= 0 [20:26:11 CEST] <kevmark> See previous messages in that thread for discussion. [20:29:09 CEST] <cone-329> ffmpeg 03Kevin Mark 07master:05feeeb813e9: libavfilter/scale: Populate ow/oh when using 0 as w/h [20:29:19 CEST] <BBB> done [20:29:25 CEST] <kevmark> Thank you, I appreciate it [20:29:34 CEST] <kevmark> I have two other patches outstanding and I believe both could stand to benefit from further review. Michael gave his thoughts on one but hasn't yet gotten back to me on my response to his concerns. The other has not received any discussion yet. I'll ping those two [20:29:39 CEST] <BBB> anyone have issues with the h264 patches? [20:29:53 CEST] <BBB> michaelni: re: h264, can I push them or did you want to wait until the fate tests are in? [20:31:40 CEST] <michaelni> BBB, IIRC i meant they are good to push if tested which IIUC they were [20:31:49 CEST] <BBB> yes they were [20:44:15 CEST] <cone-329> ffmpeg 03Anton Mitrofanov 07master:840b41b2a643: avcodec/h264_cabac: Fix CABAC+8x8dct in 4:4:4 [20:44:16 CEST] <cone-329> ffmpeg 03Anton Mitrofanov 07master:06dda70f1e7c: avcodec/h264_mb: Fix 8x8dct in lossless for new versions of x264 [20:44:17 CEST] <cone-329> ffmpeg 03Anton Mitrofanov 07master:cf231b68da11: avcodec/h264: Fix mix of lossless and lossy MBs decoding [20:47:55 CEST] <durandal_1707> how are atmos stuff stored in eac3? [20:56:03 CEST] <durandal_1707> or dts:x in dts? [20:56:55 CEST] <nevcairiel> dts:x just has a specific startcode, afaik [20:56:59 CEST] <nevcairiel> like the other dts extensions [20:57:01 CEST] <atomnuker> what codec do they use, some new one? [20:58:45 CEST] <rcombs> oh, is atmos in eac3 a thing [20:58:49 CEST] <rcombs> I thought it was just in truehd [21:32:53 CEST] <JEEB> oh, atomnuker or so mentioned it yesterday but yea - edison, joule and galileo are getting axed :D [21:32:59 CEST] <JEEB> (the x86 boards) [21:33:05 CEST] <JEEB> I am totally not surprised [21:35:22 CEST] <Gramner> did anyone even use them aside from people getting them for free? [21:40:18 CEST] <JEEB> Gramner: I actually bought an IoT kit for one of the edisons :D [21:42:30 CEST] <Gramner> ah [21:43:05 CEST] <JEEB> I only noticed the kernel patches /afterwards/ [21:43:30 CEST] <JEEB> at my previous job I looked into up-porting some of them from the jenkins-squashed publicly available patch [21:43:42 CEST] <JEEB> put a ~week into it and gave up [21:43:57 CEST] <Gramner> also x86 isn't really the first thing that comes to mind when you want some super-cheap low-power low-performance cpu for some purpose [21:47:14 CEST] <iive> what was the name of that cpu that linus worked on... crusoe? [21:47:42 CEST] <Gramner> from transmeta? yes [21:48:11 CEST] <iive> i wish that thing could make a comeback... [21:48:32 CEST] <Gramner> the concept was interesting, yes [21:48:35 CEST] <iive> a lot of people at the time wanted to be able to write native code for it directly [21:49:12 CEST] <iive> it also did provide x86 cpu with ultra-low power consumption [21:49:42 CEST] <iive> however at the time other stuff was also big power drain, like the laptop lid. [21:49:58 CEST] <iive> (backlight) [21:51:35 CEST] <atomnuker> he later complained he didn't like relying on smart compilers [21:52:20 CEST] <iive> in what sense? [22:02:34 CEST] <atomnuker> "So I've come to absolutely detest CPU's that need a lot of compiler smarts or special tuning to go fast. Life is too short to waste on in-order CPU's" [22:02:39 CEST] <atomnuker> https://linux.slashdot.org/story/15/06/30/0058243/interviews-linus-torvalds… [22:12:03 CEST] <TMM> atomnuker, that's a pretty interesting read overall [22:40:09 CEST] <tmatth> atomnuker: makes me think of https://www.sudosatirical.com/articles/theres-eighty-seven-percent-chance-l… [22:40:37 CEST] <DHE> in fairness there's only a 13% chance your first submission is good [22:42:41 CEST] <TMM> my first patch got applied! But it was adding 2 lines :P [22:44:20 CEST] <atomnuker> my first patch was 1 char [22:44:32 CEST] <nevcairiel> and still terrible? [22:44:32 CEST] <nevcairiel> :D [22:44:51 CEST] Action: J_Darnley goes to check his first patch [22:44:51 CEST] <Gramner> probably too verbose [22:45:04 CEST] <atomnuker> yet it quelled the angry voices of ds4 gamepad owners complaining the report rate was crap [22:48:28 CEST] <TMM> I don't really remember what my first ever patch anywhere was [22:48:40 CEST] <TMM> I think it was adding a feature to the chat of globulation 2 [22:49:10 CEST] <BBB> J_Darnley: if its helpful, Id go and commit the patches that were lgtmed, just to flush your queue a bit [22:49:25 CEST] <BBB> J_Darnley: Ill look at the mov file from michaelni [22:49:57 CEST] <TMM> so I got some fairly small suggestions on my patchset, should I post new versions with just those small things fixed, or wait for more reviews? [22:51:41 CEST] <durandal_1707> just make sure no overreads happen [22:52:12 CEST] <durandal_1707> and that it doesnt crash with malicious input [22:53:46 CEST] <TMM> I use bytestream for everything, that means no overreads can happen, right? [22:55:11 CEST] <durandal_1707> right. but it can still owervrite happen if you donot check it how and where you write [22:55:46 CEST] <TMM> There's a check on the motion vectors being processed, I don't think it can write outside the frames [22:56:16 CEST] <TMM> oh, I did make one fuckup, I increased the size of my ip packet header, but didn't increase the minimum size check [22:56:25 CEST] <TMM> I should probably fix that :) [23:18:30 CEST] <TMM> although that shouldn't be possible to happen at all, the demuxer creates the ip packet [23:18:39 CEST] <TMM> and it always writes a full header [23:18:54 CEST] <TMM> do I still have to check the full integrity of the ip packet in the codec? [23:19:00 CEST] <durandal_1707> yes [23:20:34 CEST] <TMM> ok [23:22:25 CEST] <TMM> I should also check the total size of the packet then I suppose [23:26:38 CEST] <TMM> the original code doesn't seem to care about the size of the packet, only that there's a minimum size for the decoding map [23:26:44 CEST] <TMM> but if there's no pixel data you can still get an overread [23:26:48 CEST] <TMM> I suppose that should be fixed [23:28:55 CEST] <TMM> hmm it seems that in some cases the original code returns the size of the ip packet when there's a data problem, sometimes it returns AVERROR_INVALIDDATA [23:29:08 CEST] <TMM> in what cases should it do what? I currently return AVERROR_INVALIDDATA in almost all cases [23:29:17 CEST] <TMM> (in my new code) [23:33:03 CEST] <atomnuker> decoders usually return the size of bytes read from the packet if they can still decode something but print errors [23:33:13 CEST] <atomnuker> else AVERROR_INVALIDDATA [23:33:45 CEST] <TMM> well, I could print that there's too little data in this frame and try to move to the next one [23:33:58 CEST] <TMM> but for this format that will never actually result in a watchable stream [23:34:07 CEST] <TMM> well, for 0x06 it may work actually [23:34:16 CEST] <atomnuker> so return AVERROR_INVALIDDATA [23:34:34 CEST] <TMM> but for 0x10 there's no iframes or anything, a missing frame will just result in the entire movie being garbage most likely [23:34:44 CEST] <atomnuker> and if decoding is ok return the number of bytes read or the packet size [23:35:09 CEST] <TMM> ok, I'll just return AVERROR_INVALIDDATA then [23:35:20 CEST] <TMM> everywhere, also where the previous code returned the buffer size [23:39:23 CEST] <atomnuker> no, that's when the decoder succeeds in decoding [23:49:55 CEST] <TMM> oh yeah, of course, I mean whenever there's an error [23:50:07 CEST] <TMM> not when decoding succeeded :) [00:00:00 CEST] --- Tue Jun 20 2017

1 0

ffmpeg.log.20170619
by burek 20 Jun '17

20 Jun '17

[00:02:51 CEST] <fiem> I'm also on Windows. Unfortunately I can not get help here [00:23:14 CEST] <Aprel> When ffprobe parses a 30-minute wtv file (Windows Recorded TV), it gives a strange number for the "duration" metadata: 23970931058. Any ideas what the time unit for this is? [00:24:19 CEST] <Aprel> An hour-long file is 35957966678 [00:25:05 CEST] <Aprel> Sorry, the 30 minute should be 23972668992 [00:26:31 CEST] <Aprel> So it doesn't even scale linearly.... But is consistent and similar across files of the same duration. Can these values be converted to realtime? [02:11:47 CEST] <kepstin> Aprel: is that just the file size (in bytes?) [02:25:55 CEST] <Aprel> kepstin: file sizes are 3,633,577,984 and 5,446,565,888 bytes, so doesn't look like it [02:28:25 CEST] <Aprel> The metadata has 2 duration fields, "Duration" and "WM/MediaOriginalRunTime". I almost always extend a recording by 2 minutes because US cable channels often run into the next hour by a few seconds. These fields seem to indicate the duration as specified by the tv guide data, and the actual length of the recording as I programmed it. [02:32:39 CEST] <Aprel> For instance I have a 30-minute episode that recorded for 31min53secs according to vlc playback. ffprobe displays 19141140000 for duration and 19135700807 for "WM/MediaOriginalRunTime", so it in fact shows the discrepancy of the extention, but in unknown and baffling time units [02:49:27 CEST] <Aprel> Here's the full ffprobe output: https://pastebin.com/T9EEVat9 [04:20:57 CEST] <hendry> hi there, I am keen to create a Custom Receiving Server for obs-studio using ffmpeg. However I noticed ffserver is deprecated? http://ffmpeg.org/index.html#ffserv [04:21:23 CEST] <hendry> What should I be using to receive a stream and convert it into a basic m3u8 stream nowadays? [06:55:35 CEST] <Aprel> To update on the WTV metadata thing: as for the original runtime attribute, in cases where the recording was interrupted (e.g. by loss of cable signal), it shows a discrepancy with the duration attribute, but otherwise isn't relevant. I still have no idea about the time unit for the duration integer, but have observed that recordings of similar length have similar values, and it scales linearly. [07:04:59 CEST] <Aprel> Ahh, finally figured it out. The time unit is 10^(-7) seconds. So multiply the duration value by 10^(-7) and you get the duration of the recording in seconds. [08:47:15 CEST] <peterburk> I'm using ffmpeg to make movie clips to study Chinese: https://pingtype.github.io/movie.html [08:48:24 CEST] <peterburk> YouTube has a limit of 50 uploads per day, so I can't upload all 1119 clips on there. Right now I'm using Google Drive, but I wish I could use YouTube. [08:49:09 CEST] <peterburk> Is there a chapter-based video format that I can use, so I can combine the clips for each level (0-6) into single videos, and have direct links to the word within the level? [08:55:11 CEST] <peterburk> And second question: The slowest part is combining the word headings with the clips. The concat command doesn't work, so I have to use the filter_complex. [08:55:48 CEST] <peterburk> This command is fast, but it gets stuck on the last frame of the first video, and doesn't show the second video (no video or audio). It works for making the clips, but not for combining the headings. [08:56:00 CEST] <peterburk> ffmpeg -f concat -safe 0 -i <(printf "file '/WordHeadings/?.mp4'\nfile '/WordClips/?.mp4'\n") -c copy "test.mp4" [08:56:09 CEST] <peterburk> This command works, but it's slow. [08:56:11 CEST] <peterburk> ffmpeg -i "WordHeadings/?.mp4" -i "WordClips/?.mp4" -v debug -strict -2 -filter_complex "[0:v] [0:a:0] [1:v] [1:a:0] concat=n=2:v=1:a=1 [v] [a]" -map "[v]" -map "[a]" "Words/?.mp4" [09:34:01 CEST] <thebombzen> peterburk: Matroska supports chapters, but I don't think YouTube understands Matroska chapters. [09:34:23 CEST] <thebombzen> as for your concat command, why is there a leading / [09:34:54 CEST] <thebombzen> the /WordHeadings/ directory almost certainly doesn't exist. Plus '?' is expanded by the shell [09:35:23 CEST] <thebombzen> but it won't be expanded by the shell unless you have quotes. Most likely you want to do something like this: [09:36:35 CEST] <peterburk> thebombzen: The full path is too long, so I cut it short to make it clearer for you. [09:36:49 CEST] <thebombzen> most likely you want to do something like this: ffmpeg -f concat -i <(for fname in WordHeadings/?.mp4 WordClips/?.mp4; do printf "file '%s'\n" "$fname"; done) [09:36:59 CEST] <peterburk> thebombzen: There isn't a ?, it's a Chinese character that your IRC client can't display. [09:37:16 CEST] <thebombzen> No, it's definitely a ?. My client can display chinese characters. [09:37:36 CEST] <thebombzen> Your client might convert it to a ? before sending though [09:37:37 CEST] <peterburk> ?????? [09:38:11 CEST] <thebombzen> it does: [09:38:24 CEST] <thebombzen> your client is probably converting them to ?s before sending [09:38:28 CEST] <thebombzen> because I can render chinese characters [09:38:37 CEST] <peterburk> Ok, blame the X-Chat devs. [09:39:09 CEST] <thebombzen> Probably. But either way, you say "it is slow" [09:39:31 CEST] <thebombzen> er, I mean, you say the concat demuxer doesn't work [09:39:42 CEST] <thebombzen> paste the complete command and output [09:39:58 CEST] <thebombzen> because you clearly modified that command so there's no way I can try to debug what's wrong with it [09:45:58 CEST] <peterburk> WordClipsWo.mp4 https://drive.google.com/open?id=0B60tEu1pyR9oajZrVFgxREs1Q3M [09:46:11 CEST] <peterburk> WordHeadingsWo.mp4 https://drive.google.com/open?id=0B60tEu1pyR9oQmFKNFBLR2pzWVk [09:46:26 CEST] <peterburk> WordsWoFailed.mp4 https://drive.google.com/open?id=0B60tEu1pyR9oM3BIak9MRmt4M00 [09:46:38 CEST] <peterburk> ffmpeg -f concat -safe 0 -i <(printf "file '/Users/peter/Desktop/WordHeadingsWo.mp4'\nfile '/Users/peter/Desktop/WordClipsWo.mp4'\n") -c copy "WordsWoFailed.mp4" [09:46:58 CEST] <peterburk> Working, but slow (still running): [09:46:58 CEST] <peterburk> ffmpeg -i "WordHeadingsWo.mp4" -i "WordClipsWo.mp4" -v debug -strict -2 -filter_complex "[0:v] [0:a:0] [1:v] [1:a:0] concat=n=2:v=1:a=1 [v] [a]" -map "[v]" -map "[a]" "WordsWo.mp4" [09:51:16 CEST] <peterburk> WordsWo.mp4 https://drive.google.com/open?id=0B60tEu1pyR9obGlEc0RFYk9mcFE [10:21:06 CEST] <thebombzen> peterburk: how did it fail? [10:25:33 CEST] <peterburk> https://pastebin.com/nWJ0Wr6j [10:25:52 CEST] <peterburk> thebombzen: Download and try to watch WordsWoFailed.mp4 from https://drive.google.com/open?id=0B60tEu1pyR9oM3BIak9MRmt4M00 [10:26:21 CEST] <peterburk> You still see that the first video clip (the heading) works fine, but the second (the movie clips) doesn't show at all. No audio, no video - nothing. [10:27:42 CEST] <thebombzen> peterburk: third time saying this [10:27:49 CEST] <thebombzen> " and the COMPLETE console output. " [10:28:08 CEST] <thebombzen> you keep saying "it doesn't work" but there's absolutely no way to help you with that if you don't post the output [10:28:51 CEST] <peterburk> thebombzen: Not working version: https://pastebin.com/wuYZcyrk [10:29:29 CEST] <thebombzen> peterburk: you're using a version of FFmpeg from 2015 [10:29:33 CEST] <thebombzen> update and try again [10:31:34 CEST] <peterburk> thebombzen: Have you even watched the WordsWoFailed.mp4 file? [10:31:53 CEST] <thebombzen> no, and I'm not going to until you use a version that isn't two years out of date [10:31:57 CEST] <thebombzen> update and try again [10:32:15 CEST] <thebombzen> I'm not going to try to help you debug a two year old version of software that's in heavy active development [10:32:49 CEST] <thebombzen> if it's still a problem when you're using the latest version *then* you should ask for help [10:33:06 CEST] <peterburk> thebombzen: Send me a download link for your personal version of ffmpeg. [10:33:22 CEST] <thebombzen> http://ffmpeg.org/ [10:33:36 CEST] <furq> https://evermeet.cx/ffmpeg/ [10:33:59 CEST] <thebombzen> furq: you're supposed to make him go onto the sidebar and click the "Downloads" panel [10:34:06 CEST] <peterburk> I downloaded https://evermeet.cx/ffmpeg/ffmpeg-86499-g1edbf5e.7z [10:34:23 CEST] <furq> thebombzen: https://vangogh.teespring.com/shirt_pic/13434219/10963543/6/619/480x9999/fr… [10:34:25 CEST] <peterburk> The Unarchiver says "Could not extract the file "ffmpeg": Unknown data format [10:34:53 CEST] <thebombzen> that's because it's a 7z archive, which unarchiver doesn't natively support [10:35:20 CEST] <thebombzen> I believe you can install p7zip with homebrew, but I don't use OS X so I can't help you extract a 7z archive on macOS [10:35:35 CEST] <peterburk> update your file compression program and try again. [10:35:47 CEST] <peterburk> Then send me a download link that works. [10:35:51 CEST] <thebombzen> It does work [10:36:00 CEST] <peterburk> It doesn't run. [10:36:09 CEST] <peterburk> It's zero KB in size. [10:36:26 CEST] <thebombzen> The download link you posted works [10:36:31 CEST] <peterburk> The 7z archive is 9.9MB, but the binary when extracted is blank. [10:36:43 CEST] <thebombzen> That's because unarchiver doesn't support 7z archives [10:36:52 CEST] <thebombzen> you said that yourself [10:37:07 CEST] <peterburk> Yeah. Upload ffmpeg in a binary format that I can use, and then I'll update to your personal version. [10:37:27 CEST] <peterburk> Two years ago I wasted an afternoon figuring out how to compile it from source and fixing all the errors. [10:37:46 CEST] <thebombzen> peterburk: I'm just some guy on the internet who is providing you tech service for free out of my own time [10:37:47 CEST] <peterburk> You won't even run my commands, even though I sent them several times, and uploaded my example files to Google Drive. [10:37:54 CEST] <thebombzen> I don't have to do this [10:38:13 CEST] <thebombzen> I would really appreciate it if you don't demand that I upload a binary that you can use [10:38:36 CEST] <thebombzen> because I've already stated that I don't use macOS. Do you want me to send you a Linux binary? I don't think you do [10:38:53 CEST] <thebombzen> I've also already explained that the file you downloaded is a 7z archive, and I even suggested you install p7zip on homebrew [10:38:56 CEST] <peterburk> Sure, send me the Linux binary, and I'll run it in my VM. [10:39:13 CEST] <thebombzen> sure, how about all the shared libraries it links to? [10:39:22 CEST] <peterburk> Exactly. [10:39:35 CEST] <peterburk> You have to package those and send it all to me. [10:39:51 CEST] <peterburk> And send me the entire dump of what's on your terminal window. Maybe some screenshots too. [10:40:19 CEST] <thebombzen> peterburk: It's hard to tell when your seriousness stops and when your trolling starts [10:40:26 CEST] <peterburk> Just so I can be absolutely sure that I'm using the exact same system as you, before I even try to reproduce your problem at my end. [10:40:56 CEST] <thebombzen> I don't even know if you want help anymore [10:41:01 CEST] <thebombzen> because trolling isn't how you get it [10:41:30 CEST] <peterburk> peters-macbook-pro:Desktop peter$ sudo brew upgrade ffmpeg [10:41:30 CEST] <peterburk> Error: ffmpeg 2.6.2 already installed [10:41:44 CEST] <thebombzen> then it appears the version on homebrew is out of date [10:41:49 CEST] <thebombzen> two years out of date [10:41:49 CEST] <peterburk> If homebrew can't update to a newer version, you need to tell me exactly which version you want. [10:42:01 CEST] <thebombzen> I believe both furq and I already provided links [10:42:44 CEST] <thebombzen> in fact, the link furq provided even has a convenient "download as DMG" option [10:42:59 CEST] <thebombzen> so why don't you try that [10:43:21 CEST] <peterburk> When I finish shaving the yak, updating homebrew, installing a new 7z extraction program, and reinstalling ffmpeg, and confirm that I have the same problem, will you listen to me then? [10:46:16 CEST] <peterburk> I upgraded homebrew, and it still thinks ffmpeg 2.6.2 is the latest version. [10:46:29 CEST] <thebombzen> peterburk: *in fact, the link furq provided even has a convenient "download as DMG" option* [10:46:49 CEST] <thebombzen> you seem to have a bad case of not listenening [10:47:42 CEST] <thebombzen> in fact, it's a bit silly to try to argue that 2.6.2 is not out of date. literally the first thing it prints is the copyright date, which is 2015. [10:48:15 CEST] <peterburk> you seem to have a bad case of blaming others. It's my IRC client's fault that Chinese characters aren't displayed. It's my fault that homebrew haven't got the latest version of ffmpeg. It's my fault that I'm using a Mac, and I should be using Linux (but which version, you won't tell me). [10:48:39 CEST] <thebombzen> I didn't say any of those things. [10:49:07 CEST] <thebombzen> Well, I did say that it isn't my fault the Chinese characters wouldn't render, but that's because my client does render chinese characters [10:49:42 CEST] <thebombzen> but I didn't say it was your fault homebrew didn't have the latest version. I just merely stated that it appears it didn't have the latest version. [10:49:56 CEST] <thebombzen> I didn't say it was your fault for using macOS, I merely said I don't use it and thus I'm unfamiliar with it [10:50:20 CEST] <thebombzen> I didn't recommend you use Linux, and I'm not sure why you thought I did [10:51:49 CEST] <thebombzen> You're tilting because you think I'm giving you unhelpful and accusatory answers. I am not, I'm just recommending you actually read the advice I provide [10:52:19 CEST] <peterburk> With the latest version: https://pastebin.com/T3BsrMHi [10:52:39 CEST] <thebombzen> that looks like it worked [10:52:57 CEST] <peterburk> Yeah, did you watch the output? [10:53:18 CEST] <thebombzen> No, because you didn't post it [10:53:21 CEST] <peterburk> You can download it here: https://drive.google.com/open?id=0B60tEu1pyR9oZHpVdUFXeGJseVk [10:53:29 CEST] <thebombzen> Also, your input video is 68 kbps [10:53:31 CEST] <thebombzen> that looks wrong [10:53:53 CEST] <peterburk> You mean like Apple said about the iPhone 4, "You're holding it wrong". [10:54:00 CEST] <peterburk> The input is correct. [10:54:08 CEST] <furq> that seems about right for a static image [10:55:01 CEST] <thebombzen> peterburk: what's wrong with the output video? [10:56:10 CEST] <thebombzen> It looks like a static image of and then a 15 minute video of whatever [10:56:13 CEST] <peterburk> The word heading looks fine (WordHeadingsWo.mp4, first 4 seconds). The movie clips (WordClipsWo.mp4, everything else) come out with no audio, and the video is all broken. [10:56:30 CEST] <thebombzen> no it doesn't? The video file plays correctly [10:56:57 CEST] <peterburk> This is what it should look like: https://drive.google.com/open?id=0B60tEu1pyR9obGlEc0RFYk9mcFE [10:57:13 CEST] <peterburk> This is what it does look like: https://drive.google.com/open?id=0B60tEu1pyR9oZHpVdUFXeGJseVk [10:58:58 CEST] <peterburk> The file is not corrupt, but the video has random squares all over it, and the audio is silent. [11:02:12 CEST] <peterburk> Here's a screenshot showing the broken video: https://drive.google.com/open?id=0B60tEu1pyR9oMjFWUmN2QmlTVDQ [11:06:48 CEST] <thebombzen> peterburk: that sounds like it's an issue with your player. I downloaded the video you produced and it works correctly [11:07:27 CEST] <peterburk> Which player are you using? [11:07:56 CEST] <thebombzen> mpv [11:08:48 CEST] <thebombzen> here's a screenshot I took with my player [11:08:48 CEST] <thebombzen> https://0x0.st/lOT.png [11:09:02 CEST] <thebombzen> I don't see any corruption artifacts [11:09:18 CEST] <peterburk> Indeed, mpv plays it just fine. [11:10:02 CEST] <thebombzen> there you go [11:10:03 CEST] <peterburk> All you have to do is persuade the rest of the world to use mpv, and that will be fine. My users will be using the built-in QuickTime Player (or maybe VLC). [11:10:17 CEST] <peterburk> Or I can just use the slow command and then the whole world can watch it. [11:10:23 CEST] <thebombzen> well, try remuxing it [11:10:34 CEST] <thebombzen> ffmpeg -i bad.mp4 -c copy good.mov or something [11:10:50 CEST] <peterburk> You mean, convert mp4 to mov? [11:11:42 CEST] <thebombzen> I mean remux [11:11:56 CEST] <peterburk> What command are you using? [11:12:10 CEST] <peterburk> Please paste the exact command from your terminal window into Pastebin. [11:12:15 CEST] <thebombzen> I literally just typed it [11:12:25 CEST] <peterburk> I did that for you, why won't you do it for me? [11:12:33 CEST] <thebombzen> I literally just typed it [11:12:39 CEST] <thebombzen> ffmpeg -i bad.mp4 -c copy good.mov [11:13:01 CEST] <peterburk> No, there is no file called bad.mp4 [11:13:09 CEST] <thebombzen> use your brain [11:13:26 CEST] <peterburk> I didn't tell you to use your brain when you forced me to waste the last 2 hours updating everything. [11:13:34 CEST] <peterburk> Send me the Pastebin link. [11:13:45 CEST] <thebombzen> Wow, you're an asshole [11:13:58 CEST] <peterburk> I'm expecting the same from you as what you demanded from me. [11:14:46 CEST] <thebombzen> I'm going to repeat what I said before. I'm just some guy on the internet providing tech support to you, for free, on my own personal time. [11:14:47 CEST] <peterburk> I don't want to use .mov format. [11:14:48 CEST] <thebombzen> I don't have to do this. [11:15:05 CEST] <thebombzen> and I'm not going to do this anymore [11:15:05 CEST] <peterburk> Ok, then I'll ask someone else tomorrow. But you just wasted 2 hours of my time. [11:15:15 CEST] <thebombzen> I really didn't [11:15:22 CEST] <peterburk> And I'll add your name to the wall of shame in my documentation. [11:15:53 CEST] <thebombzen> why don't you get a good night's sleep and look over the logs of this [11:16:19 CEST] <peterburk> Why don't you stop being a generic "system manager" saying "it works alright for me" [11:16:56 CEST] <thebombzen> Because "it works for me" means the file is not corrupt file, but rather something on your system is having trouble playing it back [11:17:02 CEST] <thebombzen> that actually means something [11:17:08 CEST] <peterburk> Not everybody who uses ffmpeg is an expert in the field of video and audio encodings. [11:17:22 CEST] <peterburk> I want to concat two video files, and it's giving me problems. [11:17:46 CEST] <thebombzen> Ah, but you see, I happen to have been using this software for about six years, and you have recognized your own lack of expertise. [11:17:56 CEST] <thebombzen> But you also are demanding that I provide you the same information you provide me [11:18:16 CEST] <thebombzen> unfortunately, this isn't quite symmetric, because I'm trying to debug your problem. My exact command is not relevent to you, but your exact command is relevant to me. [11:18:37 CEST] <peterburk> You say "use Linux and mpv and you'll be 1337 and have no problems", but to me, that's just plain arrogant. [11:18:49 CEST] <thebombzen> I didn't tell you to use Linux once [11:19:02 CEST] <peterburk> You said it doesn't work because you're using Linux and I'm using Mac OS. [11:19:03 CEST] <thebombzen> I also said that I use mpv. I did not actually ever tell you to use it [11:19:17 CEST] <thebombzen> I also did not say that it doesn't work because you're on macOS. [11:19:21 CEST] <peterburk> But you blamed my player, and said it only works in mpv. [11:19:42 CEST] <peterburk> I have a working command, with 5 hours runtime. [11:19:45 CEST] <thebombzen> Well, if a valid file does not play in your player, then it means your player is imperfect. [11:19:55 CEST] <peterburk> Yeah, go and take that to Apple. [11:20:02 CEST] <thebombzen> I also I even suggested a fix, which was to remux it [11:20:10 CEST] <peterburk> I don't know what remux means. [11:20:16 CEST] <peterburk> Does it mean to convert .mp4 to .mov? [11:20:29 CEST] <thebombzen> not really [11:20:39 CEST] <thebombzen> I did provide a command for you to use though [11:20:50 CEST] <peterburk> Yeah, but I don't have the files, and you told me to use my brain. [11:20:52 CEST] <thebombzen> which instead of trying, you just yelled that I didn't name the files exactly as they appeared on your system. [11:21:04 CEST] <peterburk> Where is bad.mp4, and what do I do with good.mov? [11:21:08 CEST] <peterburk> I want my output to be in mp4 format. [11:21:10 CEST] <thebombzen> bad.mp4 is the file that doesn't work [11:21:19 CEST] <thebombzen> I figured that would be pretty obvious [11:21:31 CEST] <peterburk> Yeah. Let's call it thebombzen.mp4 [11:21:45 CEST] <thebombzen> You do you, man [11:22:44 CEST] <peterburk> ffmpeg -i thebombzen.mp4 -c copy good.mov [11:23:23 CEST] <peterburk> Same playback problem using QuickTime Player. [11:23:36 CEST] <thebombzen> Well, then it sounds like QuickTime player is flawed. [11:23:47 CEST] <peterburk> But the slow command works. [11:23:58 CEST] <thebombzen> The slow command re-encodes the video [11:24:00 CEST] <thebombzen> this one doesn't [11:24:08 CEST] <peterburk> Well, it sounds like I need to re-encode the video. [11:24:10 CEST] <thebombzen> You could also try another container like matroska [11:24:21 CEST] <peterburk> No, my users require that my output must be mp4 [11:24:32 CEST] <thebombzen> who are your users, and why do they know that? [11:24:41 CEST] <peterburk> You said at the beginning that YouTube doesn't support matroska. [11:24:45 CEST] <thebombzen> I didn't say that [11:24:57 CEST] <peterburk> <thebombzen> peterburk: Matroska supports chapters, but I don't think YouTube understands Matroska chapters. [11:25:06 CEST] <thebombzen> Correct. YouTube supports Matroska [11:25:10 CEST] <thebombzen> it just doesn't understand matroska chapters [11:25:25 CEST] <thebombzen> You can upload matroska files to YouTube [11:25:54 CEST] <peterburk> Ok, send me the command you want me to do to make a matroska file, and I'll upload it to YouTube for you. [11:26:13 CEST] <thebombzen> the same as above, but call it good.mkv instead of good.mov [11:27:01 CEST] <thebombzen> also, why do your users need mp4? YouTube supports mov files as well [11:27:13 CEST] <thebombzen> in fact YouTube supports anything that ffmpeg should be able to read, sans licensing issues [11:37:21 CEST] <peterburk> There you go: https://www.youtube.com/watch?v=THo-IZfX458 [11:39:01 CEST] <peterburk> But I'd still rather have a slow command that generates output files that are reliable, instead of a fast command that generates output files that look messed up on many platforms. [11:43:00 CEST] <thebombzen> Well, it doesn't matter if you're distributing them through YouTube, right? [11:43:14 CEST] <thebombzen> If YouTube is able to read them correctly, then it will handle that for you [11:43:35 CEST] <thebombzen> Also, the YouTube link you provided is a deadlink [11:45:51 CEST] <peterburk> The link works on my machine: https://drive.google.com/open?id=0B60tEu1pyR9oanhTZVdyTjUyeGc [11:46:35 CEST] <thebombzen> Did you set the video to private? If so, I can't view it. [11:46:42 CEST] <peterburk> YouTube is one possible file host, but only if I can fix the chapter issue you didn't answer above. [11:47:00 CEST] <peterburk> Otherwise I'll keep using Google Drive to host it, which has the problem. [11:47:18 CEST] <thebombzen> YouTube is not a file host, it's a streaming service. It doesn't support chapter markers either [11:47:49 CEST] <peterburk> No it doesn't. But YouTube does support time offests e.g. "&t=231s" [11:48:16 CEST] <peterburk> And it would have been faster for me to write my own script to handle those than arguing with you all afternoon. [11:48:37 CEST] <thebombzen> Your impression is that this is an argument [11:49:12 CEST] <thebombzen> What's really happening is I'm spending my time providing you free tech support, even though you're constantly being beligerent [11:50:16 CEST] <peterburk> Belligerent? I met all your demands, to update my homebrew and ffmpeg versions, to share all my terminal output to PasteBin, and even to upload my input and output files. [11:50:27 CEST] <peterburk> You wouldn't even write the correct command for me. [11:50:34 CEST] <thebombzen> I didn't ask you to update homebrew [11:50:47 CEST] <thebombzen> I also didn't ask you to upload your input and output files [11:51:38 CEST] <thebombzen> I asked you to put the complete output on a paste service three times before you decided that maybe that was a good idea [11:51:48 CEST] <peterburk> I'm sick of your trolling. I'll ask my same questions again later, when there's someone who will "use their brain" on the other end. [11:52:15 CEST] <thebombzen> I am not trolling you. I am actually kind of surprised you think that [11:52:57 CEST] <thebombzen> You're getting extremely tilted about this for some reason and are reading into everything I'm saying as a personal attack [11:53:25 CEST] <thebombzen> oh, he left. [11:53:27 CEST] <thebombzen> Okay [11:58:37 CEST] <thebombzen> Guest69427: I think the easiest way to do that is to download the file to a temporary file on the hard drive, and then process it. That way you have the advantage of seekability and that sort of thing [12:10:57 CEST] <fiera> help me, please, build ffplay. I have VC 2015. to configure solution and compile project? [12:22:13 CEST] <thebombzen> fiera: do you want to build ffplay yourself or do you just want ffplay.exe? [12:22:22 CEST] <thebombzen> because if you just want ffplay.exe, there's prebuilt binaries [12:23:01 CEST] <thebombzen> if you want to build it yourself, it might be easier to use MinGW or something similar [12:26:57 CEST] <fiera> ok, Aan you step by step tell me how to do it? [12:28:26 CEST] <thebombzen> fiera: are you sure you want to build it yourself? [12:28:34 CEST] <thebombzen> or do you just want to have ffplay.exe? [12:29:58 CEST] <thebombzen> I can't actually tell you how to built FFmpeg on windows, because I don't know. I do know that you can download it prebuilt at https://ffmpeg.zeranoe.com/builds/ [12:29:58 CEST] <fiera> yes, i need build it itself [12:30:11 CEST] <thebombzen> Consider this page, this might be helpful: https://www.ffmpeg.org/platform.html#Microsoft-Visual-C_002b_002b-or-Intel-… [12:33:46 CEST] <fiera> I do not need to download. I need to build this on Windows. I can build ffmpeg, but I do not know how to compile ffpay [12:35:09 CEST] <durandal_1707> same as ffmpeg [12:36:35 CEST] <fiera> You tried? [12:37:30 CEST] <thebombzen> fiera: durandal is one of the developers [12:37:39 CEST] <thebombzen> I would trust their judgement on this ^_^ [12:38:08 CEST] <thebombzen> but yes, ffmpeg.exe, ffprobe.exe, and ffplay.exe are all built at the same time [12:38:46 CEST] <JEEB> sdl linking hasn't broken so far so all you need to do is make ffmpeg's configure find an sdl it can link against (preferably with pkg-config) [12:43:25 CEST] <fiera> thebombzen,You are wrong, I did exactly as told here https://trac.ffmpeg.org/wiki/CompilationGuide/MSVC. But I received only ffmpeg and ffprobe [12:44:23 CEST] <thebombzen> see JEEB's comment [12:44:25 CEST] <thebombzen> ffplay needs SDL [12:48:57 CEST] <fiera> i have sdl source, and sdl *.lib. Tell me, which parameter to specify the path to sdl, to compile ffplay. .\Configure --help prints the "disable sdl2 autodetect", how specify it manually? [12:52:38 CEST] <Kadigan_KSB> Hey. I'm having a bit of an understanding issue -- "Cannot connect video filter to audio output". Call + output is at https://paste.debian.net/plainh/1d4efed5 (should show as plaintext) [12:53:22 CEST] <Kadigan_KSB> (manually inserted newlines to correct for readability, command not normally this vertical) [12:54:40 CEST] <Kadigan_KSB> Also, is my understanding correct, if I'm aiming to combine video (of length X) with audio (of length Y > X) where audio will fade out as video ends w/ no additional audio w/o video? [13:02:17 CEST] <fiera> JEEB: what means "pkg-config" on Windows? [13:03:11 CEST] <JEEB> same thing? [13:03:44 CEST] <JEEB> you get a binary, you get one with msys2 f.ex. [13:03:54 CEST] <JEEB> but I'm not going to babysit you with build systems 101 [13:04:37 CEST] <JEEB> the installation of msys2 here is a sane thing, though: https://trac.ffmpeg.org/wiki/CompilationGuide/WinRT [13:05:02 CEST] <JEEB> of course you don't have to follow the stuff after YASM setup and you can move to the windows compilation guide [13:05:18 CEST] <thebombzen> Kadigan_KSB: being exactly as you wrote it is more important than modifying it to make it more readable [13:05:24 CEST] <JEEB> https://trac.ffmpeg.org/wiki/CompilationGuide/MinGW [13:07:11 CEST] <Kadigan_KSB> thebombzen: I only changed spaces to newlines, but sure -- https://pastebin.com/raw/FWTREvu8 [13:07:25 CEST] <thebombzen> Complete Console Output [13:07:33 CEST] <thebombzen> I sound like a broken record here omg [13:07:43 CEST] <Kadigan_KSB> Okay. What's incomplete about the output I pasted? [13:07:52 CEST] <thebombzen> -hide_banner [13:07:53 CEST] <thebombzen> don't do that [13:08:28 CEST] <thebombzen> the banner is helpful [13:08:38 CEST] <thebombzen> in particular because it has the version # in it [13:11:05 CEST] <Kadigan_KSB> https://pastebin.com/raw/ajFKMjRS -- is this better/complete now? [13:12:39 CEST] <thebombzen> Kadigan_KSB: yea [13:12:48 CEST] <thebombzen> I think your error is caused because fade is a video filter [13:13:03 CEST] <thebombzen> you probably want afade, not fade [13:13:27 CEST] <Kadigan_KSB> Ah, I see. [13:14:09 CEST] <Kadigan_KSB> Well, it doesn't error out any more... [13:19:44 CEST] <fiera> JEEB: You do not understand me or do not want to understand. I successfully build ffmpeg and ffpobe. I need to build the fplay. This requires sdl and I have it. I ran vcvarsall.bat, added in the include the path to the sdl, but the ffplay does not compile. I'm a Windows user, I do not understand anything in msys. Help me configure that the output i [13:19:44 CEST] <fiera> s not only ffmpeg, but also ffplay, please [13:21:00 CEST] <durandal_1707> fiera: there are explanations on wiki [13:21:34 CEST] <durandal_1707> besides you better use other player than ffplay [13:25:42 CEST] <thebombzen> fiera: if you want a CLI video player, I'd recommend mpv rather than ffplay [13:25:48 CEST] <thebombzen> ffplay is very primitive [13:26:57 CEST] <fiera> thebombzen: for my task ffplay better than mpv, i need only ffplay [13:27:14 CEST] <thebombzen> try reading the wiki articles linked then [13:28:10 CEST] <fiera> thebombzen: see last my comment [13:46:49 CEST] <Kadigan_KSB> Okay. It seems that it seeks around with the sound as well. Can I set seek for video but not for audio? [13:50:17 CEST] <Kadigan_KSB> Okay. Let's try this: I have a situation where I first do a fast seek, then a slow seek. By adding the sound file, it -seems- that it slow-seeks in the sound file now. What can I do? [13:53:45 CEST] <Kadigan_KSB> Ah, wait... wait, I'm confused. I used it as an output option because it was more accurate, so it makes sense it treats it as audio input... IIRC seek was improved, right? [14:03:17 CEST] <Kadigan_KSB> Yes. It started working as I'd expect as soon as I removed my fix for the (previously inaccurate)] input seek. [14:03:32 CEST] <thebombzen> Kadigan_KSB: "-ss" is an input option so if you put it before one input and not another, it'll only seek one of the inputs [14:03:48 CEST] <thebombzen> or rather, that is, if you're using it as an input option [14:04:00 CEST] <Kadigan_KSB> I completely forgot the entire meaning of using -ss -i -ss [14:04:29 CEST] <Kadigan_KSB> and now that I remembered (and remembered a remark that this was actually fixed to be frame-accurate now), it works. [14:04:54 CEST] <Kadigan_KSB> IIRC input seek was only keyframe-accurate or iframe-accurate or something before... [14:05:25 CEST] <Kadigan_KSB> (so I used a script to input-seek to keyframe + output-seek to specific frame) [14:07:21 CEST] <thebombzen> yea, it's as accurate as it can be. It fastseeks to the last I-frame before the timestamp, and decodes from there [14:07:37 CEST] <thebombzen> you can use -no_accurate_seek to disable this so it only seeks to I-frames [14:07:48 CEST] <thebombzen> this is enabled by default with -c copy [14:13:44 CEST] <Kadigan_KSB> I see. That's good to know. [14:13:57 CEST] <Kadigan_KSB> It's sort of obvious when you think about it. [14:14:26 CEST] <Kadigan_KSB> (since it can't copy between I-frames w/o actually recompressing, I mean) [15:29:36 CEST] <TyrfingMjolnir> How can I change the container of a file? [15:29:45 CEST] <TyrfingMjolnir> mkv to m4v as an example [15:30:04 CEST] <TyrfingMjolnir> I would like for the streams to me untouched [15:32:16 CEST] <nido> assuming one video/audio/sub stream, i think: ffmpeg -i file.mkv -acodec copy -vcodec copy -scodec copy file.mp4 [15:35:53 CEST] <Mavrik> can be shortened to ffmpeg -i file.mkv -codec copy file.mp4 [15:35:59 CEST] <Mavrik> That'll also properly copy all streams :) [15:39:56 CEST] <nido> i'll try to remember that; that sounds handy [15:43:50 CEST] <Kadigan_KSB> I was under the impression that acodec/vcodec were beind deprecated in favor of -c:a and -c:v ? [15:44:43 CEST] <Mavrik> -c:a is short for -codec:a :) [15:44:44 CEST] <Mavrik> And yes. [16:12:40 CEST] <fiera> Is there a normal way to build ffplay? [16:13:05 CEST] <fiera> i get an error i686-w64-mingw32-gcc is unable to create an executable file. [16:13:07 CEST] <fiera> wtf [16:14:55 CEST] <fiera> I do not have enough patience. Can anyone explain how to compile it? [16:40:51 CEST] <TyrfingMjolnir> fiera: use linux? [16:41:09 CEST] <TyrfingMjolnir> or ? [16:41:21 CEST] <fiera> TyrfingMjolnir: windows [16:41:28 CEST] <TyrfingMjolnir> use the same platform that you would like to compile for [16:41:44 CEST] <TyrfingMjolnir> Why is gcc unable? [16:42:11 CEST] <TyrfingMjolnir> Always paste the full error if you'd like anyone to be able to give you an answer. [16:48:49 CEST] <hendry> since ffserver is not more, what do people use to receive a rtmp stream in order to process it for HLS? [16:53:09 CEST] <iive> is it? [17:03:20 CEST] <DHE> nginx-rtmp might be able to help you. ffmpeg can connect to an rtmp server and pull content to convert to HLS itself. I'm using the ffmpeg method for an RTSP-based webcam [17:04:43 CEST] <fiera> i need ffplay itself. I did exactly as told here https://trac.ffmpeg.org/wiki/CompilationGuide/But I received only ffmpeg and ffprobe. after tried it https://trac.ffmpeg.org/wiki/CompilationGuide/MinGW/ and also do not build ffplay [17:06:22 CEST] <DHE> you need libSDL (version 2) available for ffplay to work [17:07:11 CEST] <fiera> i have sdl [17:08:56 CEST] <fiera> in msys2 typed pacman -S mingw-w64-i686-SDL. what else is it? [17:17:06 CEST] <iive> fiera: there is sdl1 and sdl2 and they are not api compatible [17:17:17 CEST] <iive> you can have both installed at the same time [17:17:27 CEST] <iive> ffplay works only with sdl2 [17:18:42 CEST] <fiera> here is verison 1.2 https://trac.ffmpeg.org/wiki/CompilationGuide/MinGW [17:23:34 CEST] <iive> i'm quite sure that recent ffmpeg version support only sdl2 [17:25:07 CEST] <iive> check what `configure --help` says about --enable-sdl2 [17:25:52 CEST] <iive> or rather --disable-sdl2 [17:26:29 CEST] <fiera> iive [17:26:29 CEST] Last message repeated 1 time(s). [17:26:29 CEST] <fiera> iive: very tnx, I intuitively executed the command "pacman -S mingw-w64-i686-SDL2". then .\configured and saw in the log "ffplay". COOL. [17:26:52 CEST] <iive> :) [17:28:02 CEST] <fiera> 2 days asked to tell this command [17:31:55 CEST] <fiera> type "make" and get and error "AR libavdevice/libavdevice.a [17:33:00 CEST] <fiera> bin/sh: i686-w64-mingw32-ar: command not found [20:57:36 CEST] <pacha> any help with this? [ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: Could not find codec parameters for stream 0 (Video: h264 (avc1 / 0x31637661), none, 1920x800, 2038 kb/s): unspecified pixel format [21:02:19 CEST] <fiera> That you are all so greedy [21:02:53 CEST] <pacha> fiera: are you responding me? [21:04:02 CEST] <fiera> pacha: It's not you, you have a problem, but no one will help you [21:04:45 CEST] <pacha> fiera: :( [21:15:08 CEST] <Diego___> Hi there. I'm working in a project that requires output video recordings to be compiled into a single one in mosaic. I've been following this guide https://trac.ffmpeg.org/wiki/Create%20a%20mosaic%20out%20of%20several%20inp… and everything works fine. The problem now is that it takes too much time to compile and quality is kinda poor. If I specify the bitrate for each video, can I get a better quality and a faster compil [21:15:51 CEST] <Diego___> Because it doesn't have to re-render frames when I change the video sizes, so it looks "logic" for myself. [21:15:59 CEST] <Diego___> Setting the proper bitrate, I mean [22:44:52 CEST] <kepstin> Diego___: hmm, that tutorial's kind of dated, you should probably use the hstack & vstack filters instead of overlay - that will speed it up somewhat [22:45:36 CEST] <kepstin> other than that, it's just a matter of setting the output encoder speed settings correctly [22:57:08 CEST] <fiera> how to remove dependencies libwinpthread-1.dll and othe, when build ffplayr? [23:11:44 CEST] <Spring> This is curious. A user finds a different concatenation tool for MKV that outputs 44MB less than ffmpeg: https://hydrogenaud.io/index.php/topic,114217/topicseen.html [23:12:00 CEST] <basisbit> by the way: time to updates and reboot all your linux or *bsd or mac os based systems. details see https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash [23:12:18 CEST] <Spring> in that particular example, obviously [23:15:58 CEST] <DHE> basisbit: interesting... [23:18:13 CEST] <kepstin> Spring: huh. be interesting to see if they get the same effect by just remuxing one of the mkvs to a new mkv on its own using mkvmerge [23:18:56 CEST] <kepstin> with mkvtoolnix* [23:21:18 CEST] <kepstin> i'm guessing that something in the mkvmerge mpeg1/2 writer must be removing parsing and removing some (unnecessary?) extra data from the mpeg video stream that ffmpeg is just leaving in (copying as-is).. [23:22:12 CEST] <kepstin> lets see, MakeMKV output, mpeg2 at 720x576, so this is probably a dvd rip. [23:22:22 CEST] Action: kepstin will try poking around with that later. [23:27:00 CEST] <fiera> help me, where get libavresample.lib. I not found it in the ffmpeg-3.3.1-win32-dev.zip ? [23:27:37 CEST] <kepstin> the ffprobe bitrate being so close to 4500+192 makes me wonder whether the video is a padded cbr, and maybe mkvmerge is removing the padding? [23:30:17 CEST] <kepstin> fiera: that the zeranoe ffmpeg build? It's build with libswresample enabled, rather than libavresample [23:47:35 CEST] <fiera> kepstin: ffplay is compiled with libavresample [23:49:41 CEST] <durandal_1707> lol no its not [23:57:43 CEST] <fiera> Very funny, like in a circus [23:58:49 CEST] <fiera> cmdutils.c , #37 line "include libavresample/avresample.h" [00:00:00 CEST] --- Tue Jun 20 2017

1 0

ffmpeg-devel.log.20170618
by burek 19 Jun '17

19 Jun '17

[00:07:28 CEST] <iive> how could performance inprove drastically in the last 48 hours?? [00:07:45 CEST] <nevcairiel> new BIOSes [00:08:41 CEST] <iive> new microcode? [00:09:06 CEST] <nevcairiel> who knows what parts exactly influence it so much [00:10:34 CEST] <iive> that's my point [00:13:56 CEST] <nevcairiel> I asked some of them if they can elaborate what exactly influences it so much, but i dont know if they know :) [00:41:24 CEST] <DHE> ryzen? [00:44:42 CEST] <iive> :) [00:48:41 CEST] <DHE> I have one of those. can confirm BIOS updates are a must... [00:48:59 CEST] <DHE> would not be surprised for a big performance boost from a bios update, probably related to RAM [01:12:33 CEST] <TMM> atomnuker, when creating a patch series for review, is it OK if some patches depend on previous patches? [01:14:18 CEST] <jamrial> TMM: yes [01:20:53 CEST] <TMM> jamrial, thanks [01:36:45 CEST] <cone-823> ffmpeg 03Michael Niedermayer 07release/3.2:b7362f3c6bc2: avcodec/hevcpred_template: Fix left shift of negative value [01:36:46 CEST] <cone-823> ffmpeg 03Michael Niedermayer 07release/3.2:74cf081ef09f: avcodec/jpeg2000dsp: Reorder operations in ict_int() to avoid 2 integer overflows [01:36:47 CEST] <cone-823> ffmpeg 03Michael Niedermayer 07release/3.2:431ccd3f55ea: Changelog: update [02:28:21 CEST] <cone-823> ffmpeg 03Daniel Kucera 07n3.2.6:HEAD: libavformat/file: return AVERROR_EOF on EOF [12:49:54 CEST] <atomnuker> is there some way to allocate around 30 floats on stack from asm? [12:52:40 CEST] <atomnuker> meh, I'll use 9 regs and live with 7 which is plenty [12:54:07 CEST] <iive> atomnuker: you can put 4'th number in cgloval, and the entry code would allocate that many bytes in the stack [12:54:37 CEST] <iive> aka, 4, 6, 6, 30*4, [12:55:18 CEST] <atomnuker> that's neat [12:56:22 CEST] <iive> rsp then points to the start of the buffer, it is also mmsize aligned. [12:58:33 CEST] <Gramner> the stack is realigned before allocating space, so if you need a certain alignment you must request a multiple of that alignment [12:59:17 CEST] <Gramner> this is useful because sometimes you intentionally want misalignment, e.g. because you want to later push some args to the stack before calling another function [13:01:15 CEST] <iive> Gramner: btw, if you don't give any number, or you put zero in there, the stack won't be touched [13:02:01 CEST] <Gramner> well yes, we don't want to execute instructions to align stuff if we don't need to [13:02:06 CEST] <iive> this means, that if i want to dynamically allocate stack space, i'd have to align myself. [13:02:34 CEST] <iive> or allocate fixed mmsize first [13:03:59 CEST] <Gramner> dynamic stack alignment is kind of evil though [13:04:13 CEST] <Gramner> just unconditionally use the maximum size instead [13:04:30 CEST] <Gramner> synamic stack allocation* [13:05:53 CEST] <Gramner> I don't think we want to use alloca() in C code either? [13:07:42 CEST] <atomnuker> we don't, libopus does and its horrible [13:10:25 CEST] <wm4> weren't you pro-VLAs a while ago [13:13:29 CEST] <atomnuker> I hadn't seen libopus [13:33:24 CEST] <BBB> J_Darnley: Ive made very slow progress, but I think Im on to something, Ive found one encoded block that indeed does not use the permutation [13:33:43 CEST] <BBB> J_Darnley: Im still tracking down where the block coding mode for that block comes from [13:35:13 CEST] <J_Darnley> Thank you [13:49:07 CEST] <BBB> michaelni: Im in mpv_decode_mb_internal, whats the easiest way to figure out what encode decision lead to a particular block choice? is there a helper macro to debug that? [13:49:24 CEST] <BBB> or which variables should I log? [13:49:38 CEST] <BBB> (I guess s->mb_intra, s->mv_dir, s->mv, etc.?) [13:51:27 CEST] <BBB> first change in decode_internal: DCT coeffs of MB at 0x0, block=2, intra=0: [13:51:40 CEST] <BBB> I think this is the second frame (its a 2-frame encode) [13:53:57 CEST] <michaelni> s->mb_intra, s->mv_dir, s->mv ,s->mv_type is an option [13:55:50 CEST] <michaelni> and ac_pred maybe [14:13:06 CEST] <BBB> DCT coeffs of MB at 0x0, block=2, intra=0, mv_dir: 1, mv_type: 0, mv: -1,-4, ac_pred: 0 [14:13:10 CEST] <BBB> thats not particularly interesting [14:14:06 CEST] <BBB> mv_type = 0 means 16x16, right? [14:14:12 CEST] <BBB> mv_dir = 1 means mv_forward [14:14:43 CEST] <BBB> maybe related to edge_mc being invoked? [14:15:48 CEST] <BBB> I think its something else though, the coefficients are much, much larger than for the other blocks around it [14:15:59 CEST] <BBB> is there a skip? [14:20:04 CEST] <BBB> yes, the residual is missing in the encode_mb step [14:20:24 CEST] <BBB> or, skip_dct[2] = 1 [14:20:54 CEST] <BBB> so I assume s->block_last_index[i] = -1; is a special thing that the encode_mb loop has to deal with? [14:21:03 CEST] <BBB> and msmpeg4enc.c doesn't? [14:21:12 CEST] <BBB> oh but this explains something else also [14:21:26 CEST] <BBB> why did it - specifically for wmv1 - have a special step to re-find the eob? [14:21:29 CEST] <BBB> now I get it [14:21:38 CEST] <BBB> because it doesnt support block_last_index = -1 [14:21:47 CEST] <BBB> so& how do you encode skip in wmv1? [14:22:20 CEST] <BBB> (msmpeg4enc.c:619) [14:22:26 CEST] <BBB> I wonder if I can just delete that code [14:23:14 CEST] <BBB> thats actually a pretty big bug and may actually have positive effects on wmv1 encoding performance [14:23:20 CEST] <BBB> insofar that we care about that [14:34:19 CEST] <BBB> or maybe I just didnt check block_last_index correctly [14:39:09 CEST] <BBB> hm ok so ignore all of that [14:39:18 CEST] <BBB> I still have a prediction error that I just cannot figure out :( [14:41:23 CEST] <BBB> pred - x: 4, y: 0, intra: 0, mvdir: 1 mv: 0/-4, mvtype: 0, mcsel: 0, qs: 0, flags: 0x800002 <- the predictor changes for the topleft 8x10 pixels in this block [14:41:31 CEST] <BBB> its not off by much, but its off [14:41:41 CEST] <BBB> the only diff is -idct simple being present or not [14:42:21 CEST] <BBB> and as far as I can see, the reference frame is identical between the two [14:42:23 CEST] <BBB> :( [14:42:52 CEST] <BBB> J_Darnley: can we just force wmv1 to continue using C? I really dont think I want to spend much more time on this [14:43:02 CEST] <BBB> J_Darnley: really, nobody in the world cares about wmv1 encoding. nobody does [14:43:08 CEST] <BBB> this isnt worth spending time at [14:43:28 CEST] <JEEB> not even wmv3/vc1 but wmv1 [14:43:30 CEST] <JEEB> yea, makes sense [14:46:27 CEST] <wm4> I'd rather ask why the fuck we have wmv encoding at all [14:46:42 CEST] <JEEB> because someone implemented it [14:47:07 CEST] <JEEB> and well, at some point it had use cases I guess [15:09:15 CEST] <BBB> is it true we dont have any msmpeg4v3 tests? [15:09:21 CEST] <BBB> not encoding and not decoding? [15:17:08 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07master:9a6503f496ae: avcodec/iff: Cleanup on init failure [15:17:09 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07master:27c20068054d: avcodec/takdec: Fixes: integer overflow in AV_SAMPLE_FMT_U8P output [15:17:10 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07master:4132218b87cd: avcodec/htmlsubtitles: Replace very slow redundant sscanf() calls by cleaner and faster code [15:17:11 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07master:14b834c45a00: avcodec/htmlsubtitles: Factor open brace handling into its own function [16:03:40 CEST] <cone-289> ffmpeg 03Hein-Pieter van Braam 07master:099d35401c1a: Cleanly exit at the end of an Interplay MVE [16:17:47 CEST] <cone-289> ffmpeg 03Marton Balint 07master:8a0932531157: avformat/rmenc: do not access AVIO write buffer directly [16:29:10 CEST] <jkqxz> wm4: Happy with <http://sprunge.us/LUUd>? I've gone back to a single array. Also the subobjects now have separate definitions. [16:33:00 CEST] <wm4> jkqxz: still worried about the consumer side of this, I guess I'll let LongChair decide (since he implemented this) [16:33:13 CEST] <wm4> on the other hand, his code and the vaapi one are separate [16:33:35 CEST] <wm4> jkqxz: why does the drm object descriptor need a size field? [16:37:38 CEST] <jkqxz> While EGL doesn't want it for import, other things do (<https://github.com/01org/libva/blob/master/va/va.h#L927>, <https://cgit.freedesktop.org/beignet/tree/include/CL/cl_intel.h#n143>). [16:37:42 CEST] <jkqxz> Also, it makes mmap() possible without huge amounts of code trying to work out what regions to map. [16:37:52 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:d2f43c48f9cd: avcodec/aacdec_template: Fix fixed point scale in decode_cce() [16:37:53 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:f0a24f2f77d1: avcodec/aacdec: Fix runtime error: signed integer overflow: 2147483520 + 255 cannot be represented in type 'int' [16:37:54 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:2e7cf081a061: avcodec/dfa: Fix: runtime error: signed integer overflow: -14202 * 196877 cannot be represented in type 'int' [16:37:55 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:fceacfc1320f: avcodec/mlpdec: Fix: runtime error: left shift of negative value -8 [16:37:56 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:3a69d5d3f01d: avcodec/fic: Fix multiple runtime error: signed integer overflow: 5793 * 419752 cannot be represented in type 'int' [16:37:57 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:08375d37be07: avcodec/mimic: Use ff_set_dimensions() to set the dimensions [16:37:58 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:51a80d0f7165: avcodec/aacsbr_fixed: Fix multiple runtime error: shift exponent 150 is too large for 32-bit type 'int' [16:37:59 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:b526aed4d580: avcodec/mlpdec: Do not leave a invalid num_primitive_matrices in the context [16:38:00 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:1476c1b2c751: avcodec/aacsbr_fixed: Fix multiple runtime error: shift exponent 170 is too large for 32-bit type 'int' [16:38:01 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:4b5920e49302: avcodec/sbrdsp_fixed: fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int' [16:38:02 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:eee339866667: avcodec/mlpdsp: Fix runtime error: signed integer overflow: -24419392 * 128 cannot be represented in type 'int' [16:38:03 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:56ce2cae385e: avcodec/takdec: Fix runtime error: left shift of negative value -63 [16:38:04 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:87de89ac7856: avcodec/aac_defines: Fix: runtime error: left shift of negative value -2 [16:38:05 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:e6d6363eb30d: avcodec/takdec: Fix runtime error: signed integer overflow: 8192 * 524308 cannot be represented in type 'int' [16:38:06 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:859188863b9d: avcodec/vmnc: Check location before use [16:38:07 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:9ac7c504eaa4: avcodec/mpeg4videodec: Check for multiple VOL headers [16:38:08 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:9a680966d1be: avcodec/aacdec_fixed: Fix runtime error: shift exponent 34 is too large for 32-bit type 'int' [16:38:09 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:a8fb8cd716df: avcodec/mjpegdec: Fix runtime error: signed integer overflow: -32767 * 130560 cannot be represented in type 'int' [16:38:10 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:7b074e728d24: avcodec/ivi_dsp: Fix multiple runtime error: left shift of negative value -71 [16:38:11 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:3b67878ab4f6: avcodec/jpeglsdec: Check get_bits_left() before decoding a picture [16:38:12 CEST] <cone-289> ffmpeg 03Max Justicz 07release/3.1:1d35eda0b2c5: avcodec/sanm: Fix uninitialized reference frames [16:38:13 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:b3f8d3880002: avcodec/jpeg2000dec: Check tile offsets [16:38:14 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:5202bef67aad: avcodec/jpeg2000dec: Fix copy and paste error [16:38:15 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:e383baee9c66: avcodec/smc: Check remaining input [16:38:16 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:b77ce15e4722: avcodec/aacdec_fixed: Fix runtime error: signed integer overflow: -2147483648 * -1 cannot be represented in type 'int' [16:38:16 CEST] <jkqxz> What are you feeling is problematic on the consumer side? [16:38:17 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:9aaadb1ee3eb: avutil/internal: Do not enable CHECKED with DEBUG [16:38:18 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:162ad001b834: avformat/mux: Fix copy an paste typo [16:38:19 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:4354def5efb7: avcodec/ra144dec: Fix runtime error: left shift of negative value -17 [16:38:20 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:f71d15f04fef: avcodec/mlpdec: Do not leave invalid values in matrix_out_ch[] on error [16:38:21 CEST] <cone-289> ffmpeg 03Kevin Mark 07release/3.1:5aaec845738b: doc/filters: Clarify scale2ref example [16:38:22 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:8da4f91fca83: avcodec/ivi_dsp: Fix runtime error: left shift of negative value -2 [16:38:23 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:9ff9355b8497: avcodec/sbrdsp_template: Fix: runtime error: signed integer overflow: 849815297 + 1315389781 cannot be represented in type 'int' [16:38:24 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:1c0524da00f0: avcodec/libfdk-aacdec: Correct buffer_size parameter [16:38:25 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:f4ff72cde6fc: avcodec/wnv1: More strict buffer size check [16:38:26 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:cadb2d590dc9: avcodec/aacdec_fixed: Fix multiple runtime error: shift exponent 127 is too large for 32-bit type 'int' [16:38:27 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:efa7ce36e372: avcodec/sheervideo: Check input buffer size before allocating and decoding [16:38:28 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:c04d2b2f9ded: avcodec/jpeg2000dec: Check tile offsets more completely [16:38:29 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:ed1a66821382: avcodec/jpeg2000: Fix runtime error: signed integer overflow: 4185 + 2147483394 cannot be represented in type 'int' [16:38:30 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:b778eb8d64c2: avcodec/snow: Fix runtime error: signed integer overflow: 1086573993 + 1086573994 cannot be represented in type 'int' [16:38:31 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:41c6624c885c: avcodec/ylc: Check count in build_vlc() [16:38:32 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:228093ec9368: avcodec/aacdec_fixed: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int' [16:38:33 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:f88fd9027c49: avcodec/webp: Fixes null pointer dereference [16:38:34 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:78603ff0f9e0: avcodec/aac_defines: Add missing () to AAC_HALF_SUM() macro [16:38:35 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:37709a5f8205: avcodec/ra144: Fix runtime error: signed integer overflow: 11184810 * 404 cannot be represented in type 'int' [16:38:36 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:b31bb8a6142c: avcodec/ra144: Fix runtime error: signed integer overflow: -2449 * 1398101 cannot be represented in type 'int' [16:38:37 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:e561676c55aa: avcodec/truemotion2: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int' [16:38:38 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:79f75b123b34: avcodec/truemotion2: Fix passing null pointer to memset() [16:38:39 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:4ba6f68b27c2: avcodec/jpeg2000dec: Use ff_set_dimensions() [16:38:40 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:f11bc174292f: avcodec/ansi: Fix frame memleak [16:38:41 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:64168825dec0: avcodec/wavpack: Fix runtime error: signed integer overflow: 24 * -2147483648 cannot be represented in type 'int' [16:38:42 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:ea70971cbe9f: avcodec/wavpack: Check float_shift [16:38:43 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:276eae8adc95: avcodec/acelp_pitch_delay: Fix runtime error: value 4.83233e+39 is outside the range of representable values of type 'float' [16:38:44 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:39c729c375a6: avformat/avidec: Limit formats in gab2 to srt and ass/ssa [16:38:45 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:2a55e8bda943: avcodec/cavsdec: Fix runtime error: signed integer overflow: 59 + 2147483600 cannot be represented in type 'int' [16:38:46 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:4911902c6f31: avcodec/pnm: Use ff_set_dimensions() [16:38:47 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:6ad05cbad1de: avcodec/ra144: Fixes runtime error: signed integer overflow: 7160 * 327138 cannot be represented in type 'int' [16:38:48 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:317690375e78: avcodec/hevc_ps: Fix runtime error: signed integer overflow: 2147483628 + 256 cannot be represented in type 'int' [16:38:49 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:89b2e25e138d: avcodec/cinepak: Check input packet size before frame reallocation [16:38:50 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:4007ba9833cb: avcodec/wavpack: Fix runtime error: signed integer overflow: 2013265955 - -134217694 cannot be represented in type 'int' [16:38:51 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:3ecefcabe076: avcodec/wavpack: Fix runtime error: shift exponent 32 is too large for 32-bit type 'int' [16:38:52 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:cc6eec316e2a: avcodec/aacps: Fix runtime error: left shift of 1073741824 by 1 places cannot be represented in type 'INTFLOAT' (aka 'int') [16:38:53 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:6af15d2d896d: avformat/options: log filename on open [16:38:54 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:80d39a5bb34d: avcodec/ac3dec_fixed: Fix runtime error: left shift of 419 by 23 places cannot be represented in type 'int' [16:38:55 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:e04d3aadc01f: avcodec/pafvideo: Check packet size and frame code before ff_reget_buffer() [16:38:56 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:0ad5a36b8b7a: avcodec/dxv: Check remaining bytes in dxv_decompress_raw() [16:38:57 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:278b8d18ad29: avcodec/hevc_ps: Fix runtime error: index 32 out of bounds for type 'uint8_t [32]' [16:38:58 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:1f4da7c38460: avutil/softfloat: Fix sign error in and improve documentation of av_int2sf() [16:38:59 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:6f49b9a68813: avcodec/qdrw: Fix null pointer dereference [16:39:00 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:e0a3b8670d27: avformat/hls: Check local file extensions [16:39:01 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:bcf63142d159: avcodec/cavs: Fix runtime error: signed integer overflow: -12648062 * 256 cannot be represented in type 'int' [16:39:02 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:42b26b41a4e6: avcodec/tiff: Avoid loosing allocated geotag values [16:39:03 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:79f0677332c3: avcodec/mjpegdec: Check that reference frame matches the current frame [16:39:04 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:e8aa646e4a23: avcodec/takdec: Fix multiple runtime error: signed integer overflow: 637072 * 4096 cannot be represented in type 'int' [16:39:05 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:fb1d3fb1e5af: avcodec/pafvideo: Fix assertion failure [16:39:06 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:faa104541d36: avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: 53098 * 40448 cannot be represented in type 'int' [16:39:07 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:cd16f4cf4b08: avcodec/ac3dec_fixed: Fix multiple runtime error: signed integer overflow: -39271008 * 59 cannot be represented in type 'int' [16:39:08 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:26afadbd2935: avcodec/indeo4: Check remaining data in Pic hdr extension parsing code [16:39:09 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:f263c4687f60: avcodec/cfhd: Check band parameters before storing them [16:39:10 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:4f2aaccff0ec: avcodec/flicvideo: Fix runtime error: signed integer overflow: 4864 * 459296 cannot be represented in type 'int' [16:39:11 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:9f5ada688051: avcodec/ra144: Fix runtime error: signed integer overflow: -2200 * 1033073 cannot be represented in type 'int' [16:39:12 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:427ee58d613a: avcodec/tiff: Fix leak of geotags[].val [16:39:13 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:7927112377b5: avcodec/aacdec_fixed: Fix runtime error: left shift of negative value -1297616 [16:39:14 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:afc6d2242cbc: avcodec/snowdec: Fix runtime error: left shift of negative value -1 [16:39:15 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:562690a7f73e: avcodec/wavpack: Fix runtime error: signed integer overflow: 1886191616 + 277872640 cannot be represented in type 'int' [16:39:16 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:3a3c32ea1f81: avcodec/jpeg2000dwt: Fix runtime error: left shift of negative value -123 [16:39:17 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:fc5bbdf2c5ab: avcodec/sbrdsp_fixed: Return an error from sbr_hf_apply_noise() if operations are impossible [16:39:18 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:fe3fcc551d71: avcodec/aacsbr_fixed: Check shift in sbr_hf_assemble() [16:39:19 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:c19fd272482e: avcodec/mpeg4videodec: Fix integer overflow in num_sprite_warping_points=2 case [16:39:20 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:5d609474f3b5: avcodec/mpeg4videodec: Check sprite delta upshift against overflowing. [16:39:21 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:8d0c353b733b: avcodec/hevc_refs: Check nb_refs in add_candidate_ref() [16:39:22 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:2d7e26277a7b: avcodec/hevcdec: Check nb_sps [16:39:23 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:3e6b7d5802f1: avcodec/jpeg2000: Fixes integer overflow in ff_jpeg2000_ceildivpow2() [16:39:24 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:cfaa5affadd5: avcodec/truemotion2: Move skip computation after checks [16:39:25 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:37c77f74c277: avcodec/shorten: Sanity check maxnlpc [16:39:26 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:d51d7b097144: avcodec/jpeg2000dec: Check nonzerobits more completely [16:39:27 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:10dc2c48ed04: avcodec/hevcdec: Fix signed integer overflow in decode_lt_rps() [16:39:28 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:2d0fd04f1619: avcodec/hevcpred_template: Fix left shift of negative value [16:39:29 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:575ba2100787: avcodec/jpeg2000dsp: Reorder operations in ict_int() to avoid 2 integer overflows [16:39:30 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:8a38efad428f: avcodec/takdec: Fixes: integer overflow in AV_SAMPLE_FMT_U8P output [16:39:31 CEST] <cone-289> ffmpeg 03Michael Niedermayer 07release/3.1:dcace98d085b: Update for 3.1.9 [16:41:18 CEST] <jkqxz> wm4: [Post git spam] What are you feeling is problematic on the consumer side? [16:41:54 CEST] <atomnuker> jamrial / nevcairiel: do you know why doing a movu from [%1q + 1*mmsize + 8 + %2] inside a macro doesn't work? [16:42:44 CEST] <atomnuker> its like the %2 index gets ignored and I load incorrect things [16:43:02 CEST] <atomnuker> incrementing %1 outside the macro works though [16:43:44 CEST] <wm4> jkqxz: determining how the planes or images are assembled [16:44:11 CEST] <wm4> basically translating it to calls that create EGL images or map DRM FBs [16:45:02 CEST] <jkqxz> I added the plane_index field to help in this one now that it isn't implicit in the structure of the nested array. [16:45:08 CEST] <wm4> I keep thinking that just a flag that tells you whether it's a format that implicitly merges both planes, or that exports separate buffers, would be the best [16:45:27 CEST] <wm4> is it possible to map a vaapi NV12 image as DRM FB? [16:45:42 CEST] <wm4> or does it have to go through VPP RGB conversion [16:46:16 CEST] <jkqxz> I think the FB on Intel has to be RGB. [16:47:31 CEST] <jkqxz> (You make the FB separately, map that to a VAAPI object, and VPP into it.) [16:48:11 CEST] <jkqxz> Or at least, I assume you do for pure DRM FBs. I've only ever done it with ones coming from DRI. [16:53:50 CEST] <wm4> jkqxz: also not sure if I get format/format_modifier [16:54:04 CEST] <wm4> shouldn't at least one of them be per object? [16:57:13 CEST] <jkqxz> Maybe modifier could be per-object, but I'm not sure whether that is a real constraint. (format definitely isn't.) [16:57:50 CEST] <wm4> huh [17:09:23 CEST] <jkqxz> Modifiers are per-object <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…>. [17:16:54 CEST] <jkqxz> wm4: New version with the modifier on the object rather than the plane <http://sprunge.us/dhXH>. [17:25:52 CEST] <wm4> seen [17:33:05 CEST] <cone-289> ffmpeg 03Paul B Mahol 07master:a23a56e77c0c: libavfilter/af_biquads: add shorter option for width_type [17:51:44 CEST] <atomnuker> durandal_1707: sorry, I couldn't finish af_noisereduct today, will have to do it during the week [17:52:32 CEST] <atomnuker> (got distracted by simd) [18:14:30 CEST] <cone-289> ffmpeg 03Mark Thompson 07master:d984b29b21f6: vf_hwmap: Add missing error code [18:14:31 CEST] <cone-289> ffmpeg 03Mark Thompson 07master:70808859ddf4: vf_hwmap: Properly free a locally derived device [18:14:32 CEST] <cone-289> ffmpeg 03Mark Thompson 07master:f434ddf48e08: avconv_hw: Free device on initialisation failure [18:35:19 CEST] <bofh_> atomnuker: got a copy of the SIMD (AVX?) fft5 that managed to be slower than the C? [18:35:27 CEST] <bofh_> I am very curious, because what. [18:35:58 CEST] <bofh_> (also, af_noisered? Ephraim-Malah noise suppression filter like the one in libspeexdsp?) [18:41:41 CEST] <atomnuker> no, FFT based [18:42:42 CEST] <atomnuker> also like I said its not slower itself, the asm code is almost 2x faster than C [18:43:14 CEST] <atomnuker> but the non-simd code I haven't done fully yet is more than 2x slower than the non-simd code with the original C stuff [18:43:55 CEST] <atomnuker> which slows the entire function down to 3/2 the speed of the C function [18:44:38 CEST] <atomnuker> happens with both clang and gcc so have no idea what's going on [19:32:02 CEST] <durandal_1707> atomnuker: how much lines have you wrote? [20:03:39 CEST] <BBB> michaelni: about mpegvideo encoding, how does reconstruction work? I still dont get that. it seems to me that encode_mb is where block choices are made, and that actually calls decode_mb, but it also seems that decode_mb parses the bitstream which seems unnecessary, so how does this work? [20:07:15 CEST] <michaelni> theres no bitstream parsing happening in the encoder [20:09:56 CEST] <michaelni> the encoder only runs the commo parts that both encoder and decoder need [20:10:23 CEST] <michaelni> these should be in ff_mpv_decode_mb() i think (the function was renamed in cleanup at some point) [20:16:20 CEST] <BBB> aha [20:16:22 CEST] <BBB> ok, that name is confusing [20:16:24 CEST] <BBB> tnx [20:16:25 CEST] <BBB> so... [20:16:51 CEST] <BBB> I see this (between -idct simple and whatever the default is) is put_dct() for the keyframe: [20:16:54 CEST] <BBB> dequant [20:16:55 CEST] <BBB> - 1342 0 0 -49 0 29 0 0 [20:16:56 CEST] <BBB> + 1342 0 0 -49 0 1 0 0 [20:17:04 CEST] <BBB> this is a de-permutated first line of s->block [20:17:24 CEST] <BBB> so & does dct_unquantize_intra depend on idct_permutation in some undocumented way? [20:17:36 CEST] <BBB> and could that screw with formats that have private scantables like wmv1? [20:17:49 CEST] <BBB> (and that dont update quantization tables with the permutation table) [20:18:02 CEST] <BBB> I believe this is the origin of the bug [20:18:10 CEST] <BBB> (dont ask me why Im still looking at this, I dont know...) [20:21:25 CEST] <BBB> ahaaaaaaaaaa [20:21:27 CEST] <BBB> yes indeed [20:21:31 CEST] <BBB> how utterly incredibly evil :D [20:21:51 CEST] <BBB> and after that the bug goes away [20:21:54 CEST] <BBB> hurray! [20:23:02 CEST] <rkern> Did the host key for source.ffmpeg.org change? [20:24:43 CEST] <BBB> rkern: about 3 months ago, yes [20:25:48 CEST] <BBB> sorry, I cant find the email right now, but it was announced I believe [20:27:19 CEST] <BBB> J_Darnley: kierank: https://pastebin.com/raarpqWR [20:27:25 CEST] <BBB> J_Darnley: and thats the last Im doing on this ;) [20:27:53 CEST] <BBB> its a little hacky but I really dont think we should care about crap like this [20:28:02 CEST] <BBB> feel free to optimize in whatever way is appropriate [20:28:30 CEST] <BBB> (the problem is that raster_end - to my knowledge - is not adjusted to the wmv1-specific scantables) [20:28:40 CEST] <BBB> but Im not 100% sure [20:33:38 CEST] <jamrial> rkern: https://mailman.videolan.org/pipermail/vlc-devel/2017-April/112787.html [21:07:30 CEST] <cone-289> ffmpeg 03Paul B Mahol 07master:478a1949d920: avfilter/af_amix: fix possible hang [21:14:06 CEST] <BBB> its also interesting how mpeg1/2 intra and inter unquantize use intra_scantable, and h263 intra/inter unquantize use inter_scantable [21:14:15 CEST] <BBB> this is not obvious and I have no friggin clue what it means [21:26:34 CEST] <atomnuker> durandal_1707: 360 lines, started from af_adelay [21:27:17 CEST] <wm4> BBB: basically mpegvideo is still a nightmare [21:27:19 CEST] <atomnuker> in hindsight, I should restart again from af_afftfilt [21:31:21 CEST] <atomnuker> durandal_1707: af_afftfilt looks wrong [21:31:54 CEST] <atomnuker> in the case that overlap is enabled [21:32:06 CEST] <atomnuker> (e.g. the window function does overlap) [21:33:33 CEST] <durandal_1707> huh? [21:36:04 CEST] <atomnuker> nevermind, I thought the overlap was incorrectly calculated [21:37:09 CEST] <atomnuker> also what's up with the avfft.c wrapper around fft.h? [21:46:00 CEST] <atomnuker> huh, didn't know we exposed an FFT/MDCT through the public api, cool [21:48:29 CEST] <atomnuker> yet stuff in libavcodec still uses the ff_mdct/fft functions, this needs cleanup, but got a million things to do first [21:51:06 CEST] <kierank> BBB: <3 [21:51:24 CEST] <BBB> you owe me beer :-p [21:52:02 CEST] <kierank> :) [22:02:35 CEST] <wbs> does anybody have logs from thursday/friday they can share? I've been mentioned but my scrollback doesn't go far enough back [22:05:28 CEST] <jamrial> wbs: https://ffmpeg.org/pipermail/ffmpeg-devel-irc/2017-June/ [22:05:44 CEST] <wbs> jamrial: thanks [22:05:58 CEST] <jamrial> and http://ffmpeg.gusari.org/irclogs/ for real time logs for the current day [22:07:04 CEST] <jamrial> ah, also full archive, now that i look closely [22:10:38 CEST] <BBB> wbs: it was probably me [22:10:57 CEST] <BBB> someone claimed that loopfilter was not aarch64 optimized for vp9 and I thought ti was, so I pinged you to confirm :-p [22:11:18 CEST] <BBB> but then it turned out to be a misunderstanding or so [22:11:24 CEST] <BBB> sorry about that [22:12:12 CEST] <atomnuker> I did test it on a raspberry pi 3, got 8 fps for 4 threads [22:12:34 CEST] <BBB> is a raspberry pi any good? [22:12:42 CEST] <BBB> (sounds like it isn't) [22:12:44 CEST] <JEEB> just popular [22:12:56 CEST] <atomnuker> its the worst money can buy, I hate it, its the most unreliable board I've ever used [22:12:58 CEST] <JEEB> also I should really install something aarch64 onto my rpi3 [22:13:09 CEST] <atomnuker> JEEB: good. luck. [22:13:12 CEST] <JEEB> :D [22:13:15 CEST] <JEEB> inorite [22:13:18 CEST] <atomnuker> archlinux has an aarch64 beta [22:13:21 CEST] <atomnuker> did it run? yes [22:13:31 CEST] <atomnuker> the one time I did manage to get it to run [22:13:34 CEST] <JEEB> fedora supposed to do it but they don't seem to have published any images [22:13:57 CEST] <atomnuker> they break the aarch64 image on a daily basis it seems so you really need to hit the date [22:14:45 CEST] <atomnuker> also there's little functionality if you go with aarch64 [22:15:03 CEST] <atomnuker> since it only supports the unmodified kernel without any blobs [22:15:23 CEST] <atomnuker> no wifi, bluetooth, audio, temperature sensor, current clockspeed [22:15:53 CEST] <JEEB> yea [22:16:13 CEST] <atomnuker> though because its archlinux rather than the most horrible outdated debian ever it'll run faster [22:16:52 CEST] <JEEB> anyways, according to some people aarch64 was "work complete" in March https://github.com/raspberrypi/linux/issues/1915 [22:58:18 CEST] <wm4> atomnuker: you mean raspbian? [22:59:44 CEST] <atomnuker> yep, the complete opposite of stable debian in every way [23:00:00 CEST] <atomnuker> stable -> nope [23:00:06 CEST] <atomnuker> outdated -> very outdated [23:09:16 CEST] <TMM> I thought arch was pretty bleeding edge [23:10:43 CEST] <nevcairiel> raspbian jessie seems to be generally OK for me, but i didnt really pay that much attention of how current it is, i only wanted a very basic system to run [23:10:44 CEST] <atomnuker> well, not archlinux arm [23:12:38 CEST] <atomnuker> the issue I think is there's no single way to boot multiple variants of boards, so distributions can't really make images to run on all these boards [23:13:17 CEST] <atomnuker> even though uboot is present on all boards each needs specific boot instructions, e.g. offset to load the kernel at [23:13:27 CEST] <JEEB> yup [23:13:46 CEST] <JEEB> although in theory EFI ARM boards would make that simpler. those just happen to be enterprise only [23:14:56 CEST] <BtbN> I'm fighting with UEFI PXE boot right now... not fun [23:15:01 CEST] <atomnuker> yep, arm servers are definitely taking over the market steadily [23:15:07 CEST] <atomnuker> ...not [23:15:12 CEST] <wm4> too bad the world is too bad of a place as that they could just agree on some simple boot standard [23:15:39 CEST] <BtbN> well, there is arm-efi and aarch64-efi [23:15:46 CEST] <iive> atomnuker: if your rpi3 is defective, you should return it. [23:15:48 CEST] <BtbN> They just decide not to use it [23:15:56 CEST] <JEEB> yup [23:16:08 CEST] <wm4> maybe it's too complex and fuckup and probably comes with license fees [23:16:15 CEST] <wm4> *fucked up [23:16:38 CEST] <JEEB> the APIs are windows-style which can e thought of as fucked up [23:16:40 CEST] <iive> i remember linus complaining about EFI complexity.... [23:16:46 CEST] <atomnuker> iive: I have 2, one which I bought not a month ago, and I can't say I trust either [23:16:47 CEST] <JEEB> but at least there's a reference implementation [23:17:04 CEST] <JEEB> (which some makers just utilize it) [23:17:53 CEST] <iive> atomnuker: what's the problem? hangs, reboots? [23:19:36 CEST] <atomnuker> kernel panics when compiling anything heavy, downloading heavily and general packaging incompetence leading to non-bootable boards on upgrades [23:20:19 CEST] <atomnuker> (did I mention the regular debian packaging team also maintains their own armhf and aarch64 package repos?) [23:20:41 CEST] <nevcairiel> i havent had any such issues in multi-hour compile jobs, but admitedly i did put heatsinks on it [23:20:58 CEST] <TMM> atomnuker, sorry, one more question :) I think I followed all of the patch submission guidelines for my last patch series but it appears nobody is replying to them. Do you think I did something wrong or am I just being impatient? I don't mind waiting but if it's being ignored because I'm an idiot I'd like to fix it :) [23:21:36 CEST] <atomnuker> nevcairiel: oh and that too, the board is the least thermoconductive variant of fiberglass and makes each chip a hotspot [23:22:13 CEST] <atomnuker> TMM: its the weekend, for some reason people here are less active during the weekend [23:22:14 CEST] <nevcairiel> its a bit silly they dont just ship it with a tiny sink, this piece is tiny and totally solves such problems [23:22:44 CEST] <iive> atomnuker: packaging is software problem. kernel panics.... might be hardware one [23:22:58 CEST] <TMM> atomnuker, you'd think people have more time on their hands :) I'll just wait then. Thanks! [23:23:00 CEST] <iive> atomnuker: do you have same problem with both boards? [23:23:11 CEST] <atomnuker> who knows, that one is 2500km away and uplugged [23:23:33 CEST] <atomnuker> haven't tried compiling ffmpeg on the new one, but it hasn't done that [23:23:50 CEST] <atomnuker> I'm 99.9% sure it was packaging incompetence and an upgrade left the other one bricked [23:24:23 CEST] <atomnuker> stupid fragile barely booting boards, this would never happen on an x86 machine [23:24:51 CEST] <nevcairiel> how do you brick something where everything stateful is on the memory card you can just re-flash [23:25:18 CEST] <atomnuker> well, its bricked until I can get to it, its 2500km away [23:37:32 CEST] <TMM> atomnuker, that sucks. We ship some payment systems based off of rpis. They do die a lot all by themselves :-/ We got the most ridiculously expensive sd cards for them now and that helps a little, but they do die rather often. [23:37:56 CEST] <JEEB> yea, they just got popular [23:38:04 CEST] <TMM> atomnuker, even the PIs themselves just crap out.RPI1 seems the most stable, but we can't source them anymore :-/ [23:38:24 CEST] <nevcairiel> pi1 is so ridicoulously slow tho [23:38:28 CEST] <JEEB> some goodwill and looking good to the public goes a long way [23:38:32 CEST] <BtbN> I configured all my "productive" RPis to reboot every night [23:38:41 CEST] <BtbN> from my experience they get unstable the longer the uptime [23:39:09 CEST] <TMM> nevcairiel, the payment system was originally built for the rpi1, we have a super stripped down openwrt based os for it and the system itself is written entirely in C. It runs fine on an underclocked rpi1 even :) [23:39:35 CEST] <TMM> underclocking the rpi2 helps a little, but now we can't get those either... [23:39:53 CEST] <TMM> so now I'm porting to rpi3, I'm anticipating even more shit [23:41:07 CEST] <BtbN> The moment I put my current SD card into the Pi3, my PC couldn't read it anymore [23:41:10 CEST] <BtbN> returns weird MMC errors [23:41:11 CEST] <atomnuker> rfkill and unload all unnecessary modules you don't need [23:41:20 CEST] <BtbN> but works perfectly fine in the Pi itself, and in an external USB reader [23:42:09 CEST] <nevcairiel> i've had weird sd card problems as well, only worked properly if i used the tiny netinstall noobs image and properly re-formatted the SD from within the rpi [23:42:45 CEST] <BtbN> The card works fine for me [23:42:47 CEST] <TMM> yeah, rpis and SD cards are really weird [23:42:56 CEST] <BtbN> just not in the internal SD card reader on my laptop [23:43:23 CEST] <TMM> I have a whole box of sd cards that will either no longer read anywhere, not read in a pi but will read in a pc, or won't read in a pc but will read in a pi [23:44:01 CEST] <nevcairiel> i have my main data on a usb drive connected to the pi, but booting from usb is still very wonky [23:44:08 CEST] <TMM> I wonder if the problem is the pi or just that sd cards ain general are crap [23:44:42 CEST] <TMM> the really expensive ones we use now at least when they die they won't read anywhere anymore :P [23:44:49 CEST] <TMM> and it takes longer for that to happen [23:45:55 CEST] <atomnuker> they sell atom-based rpi-sized x86 machines now [23:46:17 CEST] <atomnuker> unfortunately even though they come from china they're extremely expensive for what they are [23:46:23 CEST] <TMM> atomnuker, do they have the same gpio? We have custom hardware that plugs into it [23:46:32 CEST] <atomnuker> yep, they do [23:46:40 CEST] <nevcairiel> intel has a credit-card sized x86 systems [23:46:47 CEST] <atomnuker> but they're 10x the price and don't come with ram, you have to buy your own [23:46:48 CEST] <JEEB> atomnuker: also the intel edison has 100KiB+ kernel patches [23:47:31 CEST] <atomnuker> JEEB: that's like a million lines, have they been merged/looking to be merged? [23:47:55 CEST] <JEEB> some stuff have been half-merged but mostly it means that a lot of edisons are still running 3.10 or so [23:48:03 CEST] <TMM> that's pretty crap then [23:48:11 CEST] <JEEB> IIRC intel started looking into improving that but I never looked into it again [23:48:12 CEST] <TMM> I was thinking of trying the banana pis [23:48:56 CEST] <JEEB> atomnuker: I think the best part of the edison patch was that it was jenkins-squashed [23:48:59 CEST] <JEEB> so you had no idea what changes went in together [23:50:10 CEST] <JEEB> 01org/edison-linux goes up to 3.19 [23:50:21 CEST] <atomnuker> oh wow, even worse than the odroid c2s [23:50:29 CEST] <JEEB> then it seems like some andy-shev is doing something with newer kernels [23:50:34 CEST] <JEEB> https://github.com/andy-shev/linux/tree/eds [23:50:55 CEST] <atomnuker> also maybe I'm being paranoid but the thing on the picture looks very much like it doesn't have a bios [23:51:06 CEST] <atomnuker> so you can't plug a usb flash and install debian [23:51:25 CEST] <JEEB> edison? you can flash the reference UEFI implementation on it [23:51:31 CEST] <atomnuker> ... [23:51:38 CEST] <JEEB> and it will actually work [23:51:45 CEST] <JEEB> I think that's what it comes with out of the box [23:51:50 CEST] <cone-289> ffmpeg 03Marton Balint 07master:7ed6f9168b7f: fate: use do_md5sum instead of the md5 protocol for most md5 fate tests [23:52:09 CEST] <JEEB> so yea, in that sense I've only booted it with UEFI [23:52:17 CEST] <JEEB> and that should work with 32bit debian as well I guess [23:52:25 CEST] <JEEB> I think it might support 64bit as well but I never tested [23:53:35 CEST] <JEEB> but yea, just because of the long long kernel patch set I just kind of meh'd at the edison [23:53:43 CEST] <JEEB> even if by its size and being x86 it looks promising [23:53:58 CEST] <JEEB> it is fucking expensive also compared to the ARM stuff [23:54:17 CEST] <BtbN> The edison was discontinued anyway, or was it the only survivor? [23:54:33 CEST] <JEEB> no idea, I bought one in early 2015 because I happened to be working with them [23:54:40 CEST] <JEEB> and never touched it after having some random code run on its GPIO [23:55:02 CEST] Action: JEEB even has a whole "IoT set" for it with sensors etc [00:00:00 CEST] --- Mon Jun 19 2017

1 0

ffmpeg.log.20170618
by burek 19 Jun '17

19 Jun '17

[00:00:11 CEST] <FRS> ...Right. Any way ffmpeg would allow me to set the format to 4bit raw PCM? I've had a look at the formats supposed, but it doesn't go lower than 8bit sadly, and a few google searches/manpage skims came up uneventful. [00:01:56 CEST] <ChocolateArmpits> FRS, use sox [00:02:20 CEST] <FRS> Right. So I'm going to assume there's no way to do this using FFMPEG? [00:02:39 CEST] <furq> adpcm_ms is 4-bit adpcm iirc [00:02:42 CEST] <furq> if that's any use to you [00:04:19 CEST] <FRS> Hmm... though that seems to be a codec- specifying it causes ffmpeg to throw "invalid data whilst processing input" [00:05:22 CEST] <furq> works for me [00:07:40 CEST] <FRS> Hmm... not working on my end- still getting "invalid data found while processing input" (specifying the `-acodec adpcm_ms` flag for the first and only input file). [00:08:05 CEST] <furq> oh do you have a 4-bit input [00:08:17 CEST] <furq> you'll probably need sox then [00:08:43 CEST] <FRS> Alright. I'm going to assume that's a "no" for ffmpeg- thank you for assisting me :D I appreciate it. [03:23:56 CEST] <marcurling> folks, please remind me the precise term command to know precise mint version (not uname -a) [03:24:32 CEST] <DHE> wrong channel [03:24:46 CEST] <marcurling> oh, sorry, thanks [06:14:26 CEST] <johnjay> hey furq. how's it going [09:45:43 CEST] <durandal_1707> furq: i will ban anyone mentioning sox next time [09:54:35 CEST] <furq> so how do you do it with ffmpeg then [11:12:13 CEST] <durandal_1707> furq: what? to any question you do not know the answer you respond with use sox [11:13:05 CEST] <durandal_1707> the original poster of issue havent desribed problem at all [11:13:48 CEST] <durandal_1707> sox doesnt have 4bit pcm fornat either [13:50:39 CEST] <mgit> Hi, I'm trying to speed up a gameplay recording from DeSmuME played at 1/8th speed which was recorded with fraps at 7.5fps with no frames dropped. [13:50:39 CEST] <mgit> I want to speed it up to 100% speed, iow 60fps, but the result is less than satisfactory. [13:50:39 CEST] <mgit> I've been trying [13:50:39 CEST] <mgit> ffmpeg -i "input.avi" -r 60 -vf "setpts=.125*PTS" -c:v libx264 -crf 13 -qmax 25 -an "pt-1.mp4" [13:50:39 CEST] <mgit> [13:50:41 CEST] <mgit> It does work in that it outputs a 60fps video but the video is less smooth than what I expect. [13:50:43 CEST] <mgit> I tried the :rate=8 option in VLC's transcoder and I get the exact output I expected. [13:50:45 CEST] <mgit> [13:50:47 CEST] <mgit> Am I doing something wrong, is there a better way to speed it up? Appreciate any ideas on what I could try. [17:23:25 CEST] <furq> oh wow [17:23:43 CEST] <furq> l-smash does not like working with this 10GB mp4 on a box with 256MB of ram [17:27:35 CEST] <JEEB> furq: yea there are some parser issues with a lot of boxes in a file because it does a linked list or so [17:27:47 CEST] <JEEB> which means that the more boxes you have in a file the more RAM it'll take [17:27:50 CEST] <furq> boxdumper was crashing until i killed some stuff [17:27:54 CEST] <furq> and remuxer just doesn't want to know [17:27:58 CEST] <furq> i shouldn't be that surprised really [17:28:10 CEST] <furq> it's just annoying because this file is about 20MB above the size limit i need [17:28:16 CEST] <furq> i figured i'd see if --compact-size-table would help [17:28:39 CEST] <JEEB> in theory at least it shouldn't be doing the linked list stuff, but nobody has been able to have the time and effort to poke that [17:29:03 CEST] <furq> i don't suppose ffmpeg has any options for slightly reducing the size of a massive mp4 without touching the streams [17:29:23 CEST] <furq> maybe chunk_duration [17:30:19 CEST] <JEEB> ffmpeg is really a thing that demuxes everything and then remuxes [17:30:24 CEST] <JEEB> it isn't really meant for "subtle" changes [17:33:58 CEST] <furq> oh hey what's this -moov_size option in the mp4 muxer [17:34:12 CEST] <furq> is that for avoiding doing a full second pass for faststart [17:34:28 CEST] <bencoh> it is [17:34:34 CEST] <furq> neat [17:34:35 CEST] <furq> is that new [17:34:47 CEST] <bencoh> well, afaict. and not really new, no [17:35:11 CEST] <bencoh> (I've seen it years ago, so ...) [17:37:29 CEST] <mgit> could someone help me get setpts working without dropping/duplicating frames? [17:37:54 CEST] <mgit> I posted earlier but seems the room was dead [17:38:21 CEST] <furq> so chunk_duration did nothing [17:38:30 CEST] <furq> i'm not really that surprised [18:14:37 CEST] <marcurling> Yo, what is the correct -acodec value for HE_aac, please? [18:19:18 CEST] <DHE> aac with a -profile:a parameter to go with it [18:21:29 CEST] <marcurling> ty DHE [18:29:15 CEST] <mgit> am I muted or something? [18:29:43 CEST] <DHE> mgit: no, we see you. you did not describe your problem [18:30:00 CEST] <mgit> Hi, I'm trying to speed up a gameplay recording from DeSmuME played at 1/8th speed which was recorded with fraps at 7.5fps with no frames dropped. [18:30:00 CEST] <mgit> I want to speed it up to 100% speed, iow 60fps, but the result is less than satisfactory. [18:30:00 CEST] <mgit> I've been trying: [18:30:00 CEST] <mgit> [18:30:00 CEST] <mgit> ffmpeg -i "input.avi" -r 60 -vf "setpts=.125*PTS" -c:v libx264 -crf 13 -qmax 25 -an "pt-1.mp4" [18:30:01 CEST] <mgit> [18:30:03 CEST] <mgit> It does work in that it outputs a 60fps video but the video is less smooth than what I expect. [18:30:05 CEST] <mgit> I tried the :rate=8 option in VLC's transcoder and the output is exactly as smooth as what I expected. [18:30:07 CEST] <mgit> [18:30:09 CEST] <mgit> Am I doing something wrong, is there a better way to speed it up? [18:30:11 CEST] <mgit> [18:30:13 CEST] <mgit> Appreciate any ideas on what I could be doing wrong. [18:30:15 CEST] <mgit> [18:30:19 CEST] <DHE> and pasting text into IRC like that is a punishable offense [18:30:26 CEST] <furq> that's duplicating frames [18:30:38 CEST] <mgit> i know it is, I just don't know what to do about it [18:31:15 CEST] <furq> http://vpaste.net/k55YR [18:31:17 CEST] <furq> something like that [18:31:20 CEST] <mgit> my bad about the pasting all at once, didn't know it wasn't allowed btw [18:33:47 CEST] <furq> http://vpaste.net/N6mwW [18:33:49 CEST] <furq> or that, even [18:33:53 CEST] <furq> no need for a temp file [18:34:40 CEST] <furq> that'll only speed up the video, you probably want to use -af atempo in the second ffmpeg command [18:34:46 CEST] <furq> !filter atempo [18:34:46 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#atempo [18:35:02 CEST] <furq> assuming you have audio, ofc [18:40:57 CEST] <marcurling> How could I optimize aac coding for Dual Mono input? [18:45:07 CEST] <marcurling> ^gtg : Will ask tonight... [19:01:50 CEST] <mgit> thanks furq, appreciate the help. [21:22:46 CEST] <Filystyn> guys [21:22:52 CEST] <Filystyn> manual does not cover the avcodec_parameters_to_context [21:23:05 CEST] <Filystyn> + the AVstream doe snot contain codecpar [21:23:12 CEST] <Filystyn> instead it has codec what the hell [21:24:30 CEST] <Filystyn> ok i found it.. [21:24:44 CEST] <Filystyn> the function cant get the codecpar [21:25:03 CEST] <DHE> was gonna say, yes it does have a codecpar field [21:25:33 CEST] <Filystyn> can't see it oh ah [21:25:58 CEST] <Filystyn> I found the function but cant find the codecpar in AVSTream [21:26:17 CEST] <Filystyn> stop [21:26:19 CEST] <Filystyn> got it [21:26:20 CEST] <Filystyn> LOL [21:29:11 CEST] <Filystyn> thx DHE [21:29:15 CEST] <Filystyn> still you wanted to help [21:32:33 CEST] <TikityTik> Does ffmpeg webm vp8 not support -frame-parallel? [21:35:42 CEST] <furq> libvpx vp8 doesn't support frame-parallel [21:35:52 CEST] <furq> i don't think it does any multithreading [21:36:22 CEST] <verb5> Hello everyone i am trying to stream live dvbt stream from rpi to another pc where i have ffserver . if i record the live stream on the rpi with ffmpeg -i http://192.168.3.99:4242/bysid/186 -acodec libfdk_aac -b:a 96k -ac 2 -ar 44100 -c:v h264_omx -r 25 -b:v 900 test.mp4 the cpu goes on 30% [21:36:45 CEST] <verb5> if instead of recording to file i choose to send it to ffserver [21:36:50 CEST] <verb5> the cpu goes on 300% [21:37:18 CEST] <verb5> what could be wrong ? [21:38:04 CEST] <furq> probably that ffserver sucks [21:38:39 CEST] <verb5> do i need --enable-omx --enable-omx-rpi for my ffserver ? [21:38:52 CEST] <furq> i have no idea [21:38:57 CEST] <furq> you're unlikely to get any ffserver support in here [21:39:15 CEST] <furq> nobody uses it and it was supposed to have been removed entirely by now [21:39:31 CEST] <furq> if you're using h264 and aac then consider using something like nginx-rtmp instead [21:41:19 CEST] <verb5> i am not familiar with nginx-rtmp but can you tell if i can implement the same like in ffserver ( combine different streams ) [21:41:32 CEST] <furq> combine how [21:41:48 CEST] <verb5> from different sources [21:41:56 CEST] <verb5> remote sources [21:42:49 CEST] <furq> sure [21:43:02 CEST] <furq> https://github.com/arut/nginx-rtmp-module/wiki/Directives [21:44:35 CEST] <verb5> ok thanks [21:49:45 CEST] <fiem> Hi. Tell me, plesae, how to build ffplay for windows. The documentation says how to compile an ffmpeg, but there is no info about the ffplay [21:50:02 CEST] <JEEB> I think the biggest requirement is just to have SDL2 there [21:50:10 CEST] <JEEB> to link against [21:50:25 CEST] <JEEB> but I'm not sure what you'd want from ffplay [21:53:21 CEST] <fiem> ok. i have donwloaded folders .\sdl2\include and .\sdl2\lib. But how to specify the path to these folders? [22:26:39 CEST] <fiem> I'm using the VC 2015. Created an empty console project, added the ffplay.c, configured the include and lib folders. But when assembling I get more than 100 errors. What you need to do. For example: "the identifier SHOW_MODE_NONE is not found". Tell me, please. [23:09:42 CEST] <dystopia_> im getting "Unknown error occurred" when loading an .avs in ffmpeg [23:09:46 CEST] <dystopia_> anyone got any ideas [23:11:33 CEST] <dystopia_> https://pastebin.com/cWWBnDzX [23:16:08 CEST] <dystopia_> nvm [23:16:31 CEST] <dystopia_> i had 32bit avisynth with 64bit ffmpeg [23:34:14 CEST] <fiem> dystopia_, can tell me, how build ffplay? [23:59:24 CEST] <dystopia_> sorry fiem im on windows, and don't compile anything :( [23:59:34 CEST] <dystopia_> if you hang around though others should be able to help [00:00:00 CEST] --- Mon Jun 19 2017

1 0

ffmpeg-devel.log.20170617
by burek 18 Jun '17

18 Jun '17

[00:00:19 CEST] <TMM> hi all! [00:00:29 CEST] <BBB> hey [00:00:31 CEST] <TMM> I've gotten somewhere with my implementation of those interplay codecs [00:01:07 CEST] <TMM> I need to be able to copy an 8x8 block of pixels from the previous frame to the current frame with an offset that I have in bytes only. The helper functions I've found so far don't seem particularly helpful [00:01:27 CEST] <TMM> the code in question in my naive player does this : pixeldata = video_buffer_prev + (out - video_buffer_cur) + (unsigned short)op - 0xC000; [00:02:03 CEST] <TMM> so, the current offset in the current frame, on the previous frame, minus an offset (in pixels) [00:02:22 CEST] <TMM> am I allowed to just memcpy from s->last_frame? [00:03:38 CEST] <kierank> there are motion compensation (mc) functions to do this but to get the codec to work you should just memcpy for now [00:03:41 CEST] <kierank> and then fix later imo [00:04:49 CEST] <BBB> use the emulated edge mc functions instead of memcpy [00:04:55 CEST] <BBB> else youll get issues if mv points out of frame [00:04:57 CEST] <TMM> Is there documentation on those? [00:05:21 CEST] <BBB> https://www.ffmpeg.org/doxygen/2.0/structVideoDSPContext.html#aa0c5b1dc31b9… [00:06:16 CEST] <TMM> ok, so I have to convert this offset to an x,y position? [00:06:43 CEST] <BBB> yes [00:06:58 CEST] <BBB> block_w/h is 8 for you [00:07:29 CEST] <TMM> are there helpers for that too? or just divide by linewidth and take the remaineder for x? [00:07:29 CEST] <BBB> src_x/y is the current block offset x/y minus motion vector [00:07:36 CEST] <BBB> or plus motion vector [00:07:39 CEST] <BBB> yeah that works [00:07:54 CEST] <BBB> and w/h is the size of the reference frame (typically also size of this frame) [00:09:00 CEST] <TMM> do I need to create one of those VideoDSPContexts? [00:09:47 CEST] <durandal_1707> i believe interplay doesnt use those [00:12:49 CEST] <TMM> it seems to have a copy_from() function, I'm seeing it it'll work for this [00:17:06 CEST] <TMM> I thought that did something else :) [00:17:29 CEST] <TMM> it talkes about motion compensation too, I figured it was something else [00:19:21 CEST] <BBB> J_Darnley: Ill re-look at wmv1 later, Im tired :( [00:19:52 CEST] <J_Darnley> that's fine [00:20:03 CEST] <BBB> J_Darnley: I suspect something with table permutation again, but I dont have the energy to look anymore [00:20:10 CEST] <BBB> this is the last one, right? [00:20:50 CEST] <J_Darnley> there was fate-mdec-v3 bt that's probably just a subset [00:21:02 CEST] <TMM> it seems that this copy_from function takes an x,y as well, but it is based on an offset off of the current position [00:21:05 CEST] <J_Darnley> let me check that with your patch [00:21:26 CEST] <TMM> my math seems to be failing me as how to go from a byte offset to an x,y offset, I guess just the same? [00:24:56 CEST] <BBB> yes [00:25:06 CEST] <BBB> again, divided by linesize [00:33:16 CEST] <J_Darnley> BBB: yes that looks like mdec and mdec-v3 taken care of [00:33:22 CEST] <BBB> woohoo [00:33:28 CEST] <BBB> oh wait I was gonna rest [00:33:49 CEST] <J_Darnley> Yes you were, please do [00:35:59 CEST] <philipl> jkqxz: https://wiki.ubuntu.com/IntelQuickSyncVideo This seems inaccurate, and is, i think, an active document for them. [00:36:15 CEST] <philipl> jkqxz: Seems worth correcting, in some way. [00:37:16 CEST] <TMM> I got it mostly working! :D [00:37:29 CEST] <TMM> I get some artifacts now I don't get with my own implementation [00:37:40 CEST] <TMM> but it's pretty close, so small fixes I hope... [00:44:10 CEST] <TMM> Also ffplay isn't exiting on my codec :) [00:59:55 CEST] <TMM> well, this can now mostly play interplay 0x06 videos: https://github.com/hpvb/FFmpeg/tree/interplay-mve [01:00:31 CEST] <TMM> There are more artifacts than in my player, it seems that frame flipping works a little different in ffmpeg than just the straight 'stupid' flipping I did on my own player [01:03:04 CEST] <TMM> some blocks stay black in some frames, that shouldn't be possible [01:04:14 CEST] <jkqxz> philipl: Why am I reading this? Sounds like it's written by some random individual bitter about their own incompetence. [01:05:52 CEST] <philipl> jkqxz: https://insights.ubuntu.com/2017/06/16/ubuntu-desktop-weekly-update-june-16… [01:06:12 CEST] <philipl> That's an official ubuntu progress update calling that page an official description of where they think they are. [01:06:17 CEST] <philipl> I was terrified when I read it. [01:07:19 CEST] <jkqxz> Are they actually trying to troll Intel? [01:07:45 CEST] <philipl> troll by way of incompetence? [01:07:53 CEST] <philipl> "We trained him wrong, as a joke" [01:09:53 CEST] <jkqxz> No, I mean "we don't want to bother doing anything ourselves, please make everything work perfectly for us or we will keep saying how terrible intel is and how nothing works at all". [01:10:35 CEST] <TMM> oh, ffplay doesn't stop on any mve movie it seems, looks like there's another bug to fix there, wasn't my hacking :) [01:11:36 CEST] <philipl> jkqxz: That is true. But they're also saying negative things about where ffmpeg is in all this. I suppose it's not surprising. [01:15:53 CEST] <llogan> that wiki article was writting by a single user [01:16:11 CEST] <jkqxz> Tbh I'm not very interested in trying to correct that sort of thing. Idiots say stupid things about free software all the time, and trying to correct them will drag you into trying to fix everything they've broken while they abuse you. [01:16:40 CEST] <philipl> llogan: a single user who works at Canonical. [01:16:59 CEST] <philipl> so it describes what they are doing (or not doing) and how they think things work. [01:17:02 CEST] <philipl> sad panda. [01:18:46 CEST] <philipl> jkqxz: I don't blame you, but wanted to point it out. [01:18:46 CEST] <jkqxz> I know it all works, as do a load of ffmpeg and mpv users. [01:20:12 CEST] <philipl> As do I. I'm one of those happy users. [01:34:45 CEST] <wm4> lol at that ubuntu stuff [01:35:17 CEST] <wm4> if I understand this right, they're basically complaining that ffmpeg+vaapi needs too much custom glue? of course that's solved with the newer hwaccel support [01:35:33 CEST] <wm4> but still, gstreamer implemented similar things for ages??? [01:35:48 CEST] <wm4> and this is somehow about totem, which uses gstreamer [01:35:51 CEST] <wm4> so, whatever [01:39:18 CEST] <philipl> wm4: It's a disaster. The only thing Totem has ever done for me is crash. [01:41:43 CEST] <BBB> what ubuntu thing? [01:41:46 CEST] <BBB> I wanna read! [01:46:00 CEST] <philipl> scroll up. [01:46:08 CEST] <philipl> Your brain will hurt. [01:47:14 CEST] <BBB> I saw https://insights.ubuntu.com/2017/06/16/ubuntu-desktop-weekly-update-june-16… [01:47:16 CEST] <BBB> that one? [01:47:29 CEST] <philipl> https://wiki.ubuntu.com/IntelQuickSyncVideo specifically [01:47:45 CEST] <BBB> ooo that one [01:47:49 CEST] <BBB> this will be fun [01:48:07 CEST] <wm4> hm maybe this could be explained by Intel somehow trying to get Ubuntu to license their SDK? [01:48:17 CEST] <wm4> (don't know if there's such a thing) [01:49:46 CEST] <philipl> wm4: I'd almost consider that preferable. It reads like terrible terrible cluelessness to me. [02:10:50 CEST] <BBB> so heres one thing to keep in mind [02:11:15 CEST] <BBB> Im mostly concerned about the reputation damage they could do to ffmpeg, I dont care so much about hwaccel or intel :-p [02:11:39 CEST] <BBB> most people in the graphical opensource community consider ffmpeg a piece of crap [02:11:49 CEST] <BBB> and theyll do anything in their limited understanding to just make it fit that image [02:15:00 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07master:9b65dbf7349a: avcodec/gdv: Fix undefined shift [02:15:00 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07master:1edbf5e20c75: avcodec/hevcdec: Fix signed integer overflow in decode_lt_rps() [02:23:48 CEST] <wm4> they might be right, but it's still going to be less crap than most opensource GUI stuff (and now I made everyone my enemy trollol) [03:51:10 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:a9bb748cee2b: avcodec/hq_hqa: Fix: runtime error: signed integer overflow: -255 * 10180917 cannot be represented in type 'int' [03:51:11 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:b4bb262b485f: avcodec/takdec: Fix runtime error: left shift of negative value -42 [03:51:12 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:e74ec432932a: avcodec/mlpdec: Fix runtime error: left shift of negative value -1 [03:51:13 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:3814f965aa07: avcodec/flicvideo: Check frame_size before decrementing [03:51:14 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:f66f1c523258: avcodec/aacdec_template: Fix fixed point scale in decode_cce() [03:51:15 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:dd01941b9a74: avcodec/aacdec: Fix runtime error: signed integer overflow: 2147483520 + 255 cannot be represented in type 'int' [03:51:16 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:70247373a1c7: avcodec/dfa: Fix: runtime error: signed integer overflow: -14202 * 196877 cannot be represented in type 'int' [03:51:17 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:6ee9d6e32fe4: avcodec/mlpdec: Fix: runtime error: left shift of negative value -8 [03:51:18 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:4f40dac0afa7: avcodec/fic: Fix multiple runtime error: signed integer overflow: 5793 * 419752 cannot be represented in type 'int' [03:51:19 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:bc133fe409fe: avcodec/mimic: Use ff_set_dimensions() to set the dimensions [03:51:20 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:0ff8f9b8e000: avcodec/aacsbr_fixed: Fix multiple runtime error: shift exponent 150 is too large for 32-bit type 'int' [03:51:21 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:1d52ed4da8b5: avcodec/mlpdec: Do not leave a invalid num_primitive_matrices in the context [03:51:22 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:f5212833b2e2: avcodec/aacsbr_fixed: Fix multiple runtime error: shift exponent 170 is too large for 32-bit type 'int' [03:51:23 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:90ff230fd18e: avcodec/sbrdsp_fixed: fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int' [03:51:24 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:e1e7b75cbf8b: avcodec/mlpdsp: Fix runtime error: signed integer overflow: -24419392 * 128 cannot be represented in type 'int' [03:51:25 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:20363bef602d: avcodec/takdec: Fix runtime error: left shift of negative value -63 [03:51:26 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:bc95cd148017: avcodec/aac_defines: Fix: runtime error: left shift of negative value -2 [03:51:27 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:228b1e3f40a3: avcodec/takdec: Fix runtime error: signed integer overflow: 8192 * 524308 cannot be represented in type 'int' [03:51:28 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:eed9fc2f61a3: avcodec/vmnc: Check location before use [03:51:29 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:510f968849c4: avcodec/mpeg4videodec: Check for multiple VOL headers [03:51:30 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:43db1288dd9a: avcodec/aacdec_fixed: Fix runtime error: shift exponent 34 is too large for 32-bit type 'int' [03:51:31 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:a7f35b7f358b: avcodec/mjpegdec: Fix runtime error: signed integer overflow: -32767 * 130560 cannot be represented in type 'int' [03:51:32 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:3b0f0dab4aed: avcodec/ivi_dsp: Fix multiple runtime error: left shift of negative value -71 [03:51:33 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:8d7ccdf873ad: avcodec/jpeglsdec: Check get_bits_left() before decoding a picture [03:51:34 CEST] <cone-785> ffmpeg 03Max Justicz 07release/3.2:66aa3c61fe89: avcodec/sanm: Fix uninitialized reference frames [03:51:35 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:6b1a01f3ec84: avcodec/jpeg2000dec: Check tile offsets [03:51:36 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:fdba18c0683b: avcodec/jpeg2000dec: Fix copy and paste error [03:51:37 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:8cbe7461b364: avcodec/diracdec: Fix off by 1 error in quant check [03:51:38 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:c41902278903: avcodec/smc: Check remaining input [03:51:39 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:7072201271d3: avcodec/aacdec_fixed: Fix runtime error: signed integer overflow: -2147483648 * -1 cannot be represented in type 'int' [03:51:40 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:af71771a6ce3: avutil/internal: Do not enable CHECKED with DEBUG [03:51:41 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:9b27474cdfd8: avformat/mux: Fix copy an paste typo [03:51:42 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:288eb8b17ef5: avcodec/ra144dec: Fix runtime error: left shift of negative value -17 [03:51:43 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:1e74ee34f978: avcodec/mlpdec: Do not leave invalid values in matrix_out_ch[] on error [03:51:44 CEST] <cone-785> ffmpeg 03Kevin Mark 07release/3.2:706bbb22b1b3: doc/filters: Clarify scale2ref example [03:51:45 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:6eb1a6f48b17: avcodec/ivi_dsp: Fix runtime error: left shift of negative value -2 [03:51:46 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:e7776cedf586: avcodec/sbrdsp_template: Fix: runtime error: signed integer overflow: 849815297 + 1315389781 cannot be represented in type 'int' [03:51:47 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:e18bd51596b7: avcodec/libfdk-aacdec: Correct buffer_size parameter [03:51:48 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:7108189a54f3: avcodec/wnv1: More strict buffer size check [03:51:49 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:b1da01c05169: avcodec/aacdec_fixed: Fix multiple runtime error: shift exponent 127 is too large for 32-bit type 'int' [03:51:50 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:f5839a782669: avcodec/sheervideo: Check input buffer size before allocating and decoding [03:51:51 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:f720b436152a: avcodec/jpeg2000dec: Check tile offsets more completely [03:51:52 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:ee202d98ce18: avcodec/jpeg2000: Fix runtime error: signed integer overflow: 4185 + 2147483394 cannot be represented in type 'int' [03:51:53 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:2b220944e98a: avcodec/snow: Fix runtime error: signed integer overflow: 1086573993 + 1086573994 cannot be represented in type 'int' [03:51:54 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:b08f7e592f89: avcodec/ylc: Check count in build_vlc() [03:51:55 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:a871e42e30c3: avcodec/aacdec_fixed: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int' [03:51:56 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:66c9e5e3eb43: avcodec/webp: Fixes null pointer dereference [03:51:57 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:1b048028a71d: avcodec/aac_defines: Add missing () to AAC_HALF_SUM() macro [03:51:58 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:efe4dbb6e650: avcodec/ra144: Fix runtime error: signed integer overflow: 11184810 * 404 cannot be represented in type 'int' [03:51:59 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:5b6d056da8a1: avcodec/ra144: Fix runtime error: signed integer overflow: -2449 * 1398101 cannot be represented in type 'int' [03:52:00 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:362a98eea9b8: avcodec/truemotion2: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int' [03:52:01 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:ba925988efe7: avcodec/truemotion2: Fix passing null pointer to memset() [03:52:02 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:1d4199e02311: avcodec/jpeg2000dec: Use ff_set_dimensions() [03:52:03 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:9f8da7e2aa62: avcodec/dds: Fix runtime error: left shift of 145 by 24 places cannot be represented in type 'int' [03:52:04 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:df7f051f4dbf: avcodec/ansi: Fix frame memleak [03:52:05 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:b424fde5decd: avcodec/wavpack: Fix runtime error: signed integer overflow: 24 * -2147483648 cannot be represented in type 'int' [03:52:06 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:d5f5d2132277: avcodec/wavpack: Check float_shift [03:52:07 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:625fb0895980: avcodec/acelp_pitch_delay: Fix runtime error: value 4.83233e+39 is outside the range of representable values of type 'float' [03:52:08 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:5415c88e3706: avformat/avidec: Limit formats in gab2 to srt and ass/ssa [03:52:09 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:79a5cac07754: avcodec/cavsdec: Fix runtime error: signed integer overflow: 59 + 2147483600 cannot be represented in type 'int' [03:52:10 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:ccc598dbcb79: avcodec/pnm: Use ff_set_dimensions() [03:52:11 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:cb14b289bc99: avcodec/ra144: Fixes runtime error: signed integer overflow: 7160 * 327138 cannot be represented in type 'int' [03:52:12 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:64ecc9eda976: avcodec/hevc_ps: Fix runtime error: signed integer overflow: 2147483628 + 256 cannot be represented in type 'int' [03:52:13 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:1d6983c89907: avcodec/cinepak: Check input packet size before frame reallocation [03:52:14 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:fe2a92cfd43d: avcodec/wavpack: Fix runtime error: signed integer overflow: 2013265955 - -134217694 cannot be represented in type 'int' [03:52:15 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:a8643da03a98: avcodec/cfhd: Fix runtime error: signed integer overflow: 65280 * 65288 cannot be represented in type 'int' [03:52:16 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:b7afa9f8aad0: avcodec/wavpack: Fix runtime error: shift exponent 32 is too large for 32-bit type 'int' [03:52:17 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:6a44539bc800: avcodec/aacps: Fix runtime error: left shift of 1073741824 by 1 places cannot be represented in type 'INTFLOAT' (aka 'int') [03:52:18 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:858adb27a0c9: avformat/options: log filename on open [03:52:19 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:7edf95874053: avcodec/ac3dec_fixed: Fix runtime error: left shift of 419 by 23 places cannot be represented in type 'int' [03:52:20 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:90c38d6ab8df: avcodec/pafvideo: Check packet size and frame code before ff_reget_buffer() [03:52:21 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:439757d38a6a: avcodec/dxv: Check remaining bytes in dxv_decompress_raw() [03:52:22 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:5c2c0979e243: avcodec/hevc_ps: Fix runtime error: index 32 out of bounds for type 'uint8_t [32]' [03:52:23 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:25b7dc959a08: avutil/softfloat: Fix sign error in and improve documentation of av_int2sf() [03:52:24 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:5c82f67012c3: avcodec/qdrw: Fix null pointer dereference [03:52:25 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:25dac3128b60: avformat/hls: Check local file extensions [03:52:26 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:fb0d1cafab1d: avcodec/cavs: Fix runtime error: signed integer overflow: -12648062 * 256 cannot be represented in type 'int' [03:52:27 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:260a286e5308: avcodec/tiff: Avoid loosing allocated geotag values [03:52:28 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:873397e27e97: avcodec/mjpegdec: Check that reference frame matches the current frame [03:52:29 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:f865aa6beeb4: avcodec/takdec: Fix multiple runtime error: signed integer overflow: 637072 * 4096 cannot be represented in type 'int' [03:52:30 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:fe5b764e6aa9: avcodec/pafvideo: Fix assertion failure [03:52:31 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:d5284145680f: avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: 53098 * 40448 cannot be represented in type 'int' [03:52:32 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:f7ea74422f25: avcodec/ac3dec_fixed: Fix multiple runtime error: signed integer overflow: -39271008 * 59 cannot be represented in type 'int' [03:52:33 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:e93ffb488844: avcodec/indeo4: Check remaining data in Pic hdr extension parsing code [03:52:34 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:e5714e4ccbc9: avcodec/h264_parse: Check picture structure when initializig weight table [03:52:35 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:1f1b73cb1666: avcodec/cfhd: Check band parameters before storing them [03:52:36 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:ef157cec8130: avcodec/flicvideo: Fix runtime error: signed integer overflow: 4864 * 459296 cannot be represented in type 'int' [03:52:37 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:9a8419541f2b: avcodec/ra144: Fix runtime error: signed integer overflow: -2200 * 1033073 cannot be represented in type 'int' [03:52:38 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:722cbfc5e163: avcodec/tiff: Fix leak of geotags[].val [03:52:39 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:1df854736646: avcodec/aacdec_fixed: Fix runtime error: left shift of negative value -1297616 [03:52:40 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:753d04b618e7: avcodec/snowdec: Fix runtime error: left shift of negative value -1 [03:52:41 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:266ecedc75f2: avcodec/wavpack: Fix runtime error: signed integer overflow: 1886191616 + 277872640 cannot be represented in type 'int' [03:52:42 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:61bf10368c2b: avcodec/jpeg2000dwt: Fix runtime error: left shift of negative value -123 [03:52:43 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:22a6713ce9e1: avcodec/libvpxdec: Check that display dimensions fit in the storage dimensions [03:52:44 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:15a408f1822f: avcodec/sbrdsp_fixed: Return an error from sbr_hf_apply_noise() if operations are impossible [03:52:45 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:c1e2c1e84e3a: avcodec/aacsbr_fixed: Check shift in sbr_hf_assemble() [03:52:46 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:46acaabd2a13: avcodec/mpeg4videodec: Fix integer overflow in num_sprite_warping_points=2 case [03:52:47 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:3c6aa2e0d12f: avcodec/mpeg4videodec: Check sprite delta upshift against overflowing. [03:52:48 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:81527019b1d1: avcodec/hevc_refs: Check nb_refs in add_candidate_ref() [03:52:49 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:6d77a3ff3cd8: avcodec/hevcdec: Check nb_sps [03:52:50 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:31c1c0b46a70: avcodec/dnxhd_parser: Do not return invalid value from dnxhd_find_frame_end() on error [03:52:51 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:d09ec6c27f85: avcodec/jpeg2000: Fixes integer overflow in ff_jpeg2000_ceildivpow2() [03:52:52 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:39d9308b992a: avcodec/truemotion2: Move skip computation after checks [03:52:53 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:12cf6ace44f6: avcodec/shorten: Sanity check maxnlpc [03:52:54 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:c00ef60abda2: avcodec/jpeg2000dec: Check nonzerobits more completely [03:52:55 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:a2055f8e3f14: avcodec/hevcdec: Fix signed integer overflow in decode_lt_rps() [03:52:56 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07release/3.2:1a54f239ad00: Update for 3.2.6 [04:13:01 CEST] <atomnuker> 999 decicycles in fft5_c, 4193700 runs, 604 skips vs 838 decicycles in fft5_avx, 4193746 runs, 558 skips [04:13:20 CEST] <atomnuker> just being faster than C is an accomplishment [04:14:10 CEST] <atomnuker> moreover I use 5 shufps one or two of which are redundant [04:15:19 CEST] <atomnuker> (also its really meant to be a macro which gets put inside the 15-point fft rather than a function) [04:37:10 CEST] <atomnuker> here's the code if someone wants to see it: https://pars.ee/temp/mdct15_v1.txt [04:40:23 CEST] <jamrial> atomnuker: use xorps with constants using INT32_MIN instead of -1.0 [04:42:53 CEST] <jamrial> and instead of pand/por (which btw are integer instructions, not float) with those masks, just use shufps [04:45:49 CEST] <jamrial> vfmsubadd123ps is fma3, not avx. also use "fmsubadd dst, src1, src2, src3" instead [04:58:11 CEST] <atomnuker> what difference does it make when using integer instructions on floats? [05:01:48 CEST] <rcombs> using integer instructions and then using float instructions involves some sort of internal context switch [05:02:05 CEST] <rcombs> I dunno exactly how it works but it's slow [05:02:32 CEST] <rcombs> something something pipeline something [05:03:25 CEST] <rcombs> it's why there are floating-point and integer versions of what look like they should be type-agnostic instructions, like xorps, movaps, etc [05:04:40 CEST] <atomnuker> I should probably be using the float unpack too [05:05:48 CEST] <rcombs> the floating-point instructions have the disadvantage of running on fewer ports than the integer ones, though [05:06:17 CEST] <rcombs> and the bypass-delay penalty is generally pretty small [05:07:01 CEST] <rcombs> so if you've got a bunch of operations to do that have both float and integer variants, and they could be parallelized, you probably want the int versions [05:07:26 CEST] <rcombs> but otherwise, try to stick to the same type for everything [05:07:38 CEST] <rcombs> jamrial almost certainly can explain this better than I can [05:22:09 CEST] <atomnuker> its certainly a bit faster though (a few tens of decicycles) [05:23:32 CEST] <atomnuker> crap its 4:23 and its already practically day outside [05:24:07 CEST] <atomnuker> (its still light enough to read a book outside at 3:45 what's the point of going to sleep anyway?) [09:39:24 CEST] <LongChair> jkqxz: you around ? :) [11:29:53 CEST] <TMM> does ffplay have a feature to start off paused on the first frame? [11:30:03 CEST] <TMM> I need to do some debugging and that'd be really helpful [11:33:01 CEST] <ubitux> try to is->paused = 1 before the call to event_loop()? [11:36:57 CEST] <TMM> ok! I thought perhaps ffplay had a feature for it [11:37:29 CEST] <ubitux> can't see any afaict [11:37:41 CEST] <ubitux> if the hack work you may want to submit a patch [11:37:45 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vHhUV [11:37:45 CEST] <KGB> 13FFV1/06master 14330ccde 15Dave Rice: extend intro and add summary of version history... [11:37:45 CEST] <TMM> you tried with CAPT.MVE? [11:38:08 CEST] <ubitux> i don't know what CAPT.MVE is [11:38:23 CEST] <TMM> oh, sorry, the artifacts I see are only on the new codec I'm implementing [11:38:27 CEST] <TMM> I thought perhaps you tried my code [11:38:35 CEST] <ubitux> sorry, no :) [11:43:09 CEST] <TMM> I still have one frame that's broken, it's weird [11:43:17 CEST] <TMM> in my own player that frame doesn't appear at all [11:43:40 CEST] <TMM> I don't suppose ffplay will ever show a frame that was 'half done' or something, if my codec didn't do something wrong? [11:45:56 CEST] <TMM> (my own player uses no ffmpeg code, and does super 'dumb' frame flipping, just 2 buffers that get flipped, drawing of the next frame continues on the data already there from the second last frame) [11:54:23 CEST] <jkqxz> LongChair: Yes. (Generally it's easier to just assume I'll always see things eventually if you write here.) [12:06:42 CEST] <LongChair> ok cool :) [12:07:01 CEST] <LongChair> jkqxz: not sure if you saw the links i posted in PM [12:07:16 CEST] <LongChair> i have tried to adjust my MPP stuff to your sample [12:07:24 CEST] <LongChair> but i have a few more questions [12:07:46 CEST] <LongChair> i'm not sure where AVDRMDeviceContext and AVDRMFramesContext should be created [12:11:18 CEST] <jkqxz> Did you have any thoughts on the question above about associating DRM formats with planes? [12:12:32 CEST] <jkqxz> After some thought I think it goes with each plane, rather than global (v1) or per-object (v2). That is in order to fit with the EGL import use. [12:13:06 CEST] <LongChair> hmmm [12:13:28 CEST] <jkqxz> So, DRM_FORMAT_NV12 wouldn't be used at all in the desktop cases - it would be an R8 plane and an RG88 plane, in one object or two. [12:13:50 CEST] <LongChair> So we'd need to have an array for formats i guess [12:13:53 CEST] <jkqxz> It would only be used if the platform actually has magic multiple-plane things which are supported in single calls (as Rockchip appears to). [12:14:02 CEST] <jkqxz> It would go in the planes object. [12:14:10 CEST] <LongChair> well rockchip mainly uses NV12 [12:14:16 CEST] <jkqxz> (I haven't updated anything after the second version yet.) [12:14:55 CEST] <LongChair> i have pushed some of you code (aside the vaapi specifics) and update my code to use that [12:15:27 CEST] <LongChair> see the last commits here : https://github.com/LongChair/FFmpeg/commits/rockchip [12:15:37 CEST] <jkqxz> Yeah, ignore the VAAPI stuff in your code, that's just testing what is wanted elsewhere. [12:16:03 CEST] <jkqxz> You didn't see the second version above? [12:16:18 CEST] <LongChair> i don't think so [12:16:31 CEST] <LongChair> maybe i was psoted before i connected from home [12:16:38 CEST] <LongChair> can you share the link again N [12:16:38 CEST] <jkqxz> <http://sprunge.us/fVaM> [12:17:18 CEST] <jkqxz> I think the DRM format bit needs to move from objects to planes. [12:18:23 CEST] <LongChair> hmmm [12:18:43 CEST] <LongChair> possibly [12:19:07 CEST] <LongChair> and the format-Modifier ? [12:19:42 CEST] <LongChair> i need to get a quick lunch bb in 30 mins or so :) i'd like to move one this conversation :) [12:19:51 CEST] <jkqxz> Probably the same? Though objects are likely tiled completely, so don't know. [12:21:26 CEST] <jkqxz> I don't know what other format modifiers there might be - only ones doing tiling things currently exist (<https://cgit.freedesktop.org/mesa/drm/tree/include/drm/drm_fourcc.h#n165>). [12:26:30 CEST] <jkqxz> Does the EGL import for Rockchip actually require the second plane of the NV12 image? I wonder whether it's just ignored - that would match the normal EGL use in mpv. [12:27:05 CEST] <jkqxz> (That is, you give it one "plane" which is DRM_FORMAT_NV12, and that becomes the object.) [12:42:31 CEST] <TMM> it appears that this codec keeps three buffers, one of the buffers being the current display buffer, it only seems to copy blocks changed from the previous buffers over, which it has to keep it appears [12:42:37 CEST] <TMM> I'm so confused as to how to do this properly [12:43:18 CEST] <TMM> it copies the changed blocks over, but it still expects to have access to the previous data on that frame that *doesn't* contain these changed blocks 2 frames later [12:43:41 CEST] <TMM> I feel I'm missing something really fundamental here, but I just don't understand what [12:45:19 CEST] <TMM> what I mean is that it appears to want to copy blocks from the second last frame, but that is not the frame actually displayed but the frame decoded to [12:46:32 CEST] <TMM> in my own player I solved this by having the two buffers to decode to, and then for the display buffer I'd only copy changed blocks [12:46:50 CEST] <TMM> but I'm not sure how to do this in ffmpeg, or if this is even really what I should be doing [12:47:02 CEST] <LongChair> jkqxz: back [12:48:06 CEST] <TMM> I think it expects to be able to copy a block from before the last time it was changed, not from the previous frame(s) [12:48:29 CEST] <LongChair> jkqxz: well for EGL and NV12, the dmabuf import will use like 2 planes [12:48:55 CEST] <LongChair> they have same fd but different offset / pitches [12:49:07 CEST] <LongChair> https://github.com/LongChair/mpv/blob/rockchip/video/out/opengl/hwdec_drmpr… [12:50:37 CEST] <LongChair> you have a set of fds / offsets / pitches to set ... those are interpreted by the gpu driver depending on the DRM FORMAT [12:50:45 CEST] <jkqxz> Yes, I mean: in that code, does it still work if you don't bother to supply the second plane? [12:50:59 CEST] <TMM> I guess I'll just have to allocate two more frames and just keep rotating them like in my original player? [12:51:26 CEST] <TMM> and do the final copy to the display frame separately [12:51:35 CEST] <LongChair> jkqxz: for EGL and dmabuf import there is no way to provide several formats [12:51:53 CEST] <LongChair> there is only one EGL_LINUX_DRM_FOURCC_EXT [12:52:26 CEST] <jkqxz> That's why I'm asking the question. [12:52:31 CEST] <LongChair> and several EGL_DMA_BUF_PLANE<X>_FD_EXT ... [12:52:44 CEST] <TMM> does any of that make sense at all? :) [12:53:12 CEST] <jkqxz> NV12 import on the desktop platforms doesn't have the NV12 format, so you make two separate images which are R8 and RG88. [12:54:12 CEST] <jkqxz> Hmm. <https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_i…> does say you need both planes. [12:54:33 CEST] <jkqxz> So maybe rather than talking about planes in the frame descriptor, we should instead be talking about images which contain planes. [12:55:54 CEST] <jkqxz> That is, { int nb_images; struct { uint32_t drm_format; ... modifiers? ...; int nb_planes; struct { int index; ptrdiff_t offset; ptrdiff_t pitch; } planes[N]; } } [12:56:20 CEST] <LongChair> so NV12 would be one image with 2 planes ? and for desktop two images with one plane eash ? [12:56:24 CEST] <LongChair> each* [12:56:29 CEST] <jkqxz> Yes. [12:56:55 CEST] <LongChair> i suppose this makes sense :) [12:57:21 CEST] <jkqxz> wm4: ^ ? [12:57:50 CEST] <LongChair> for the modifiers part i have no idea what a modifier is ... never used any .. but i suppose they should be at the same place than formats [13:00:42 CEST] <jkqxz> Aha! They are per-plane: <https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_i…>. [13:00:51 CEST] <jkqxz> At least that's clear. [13:01:37 CEST] <LongChair> jkqxz: yeah seems right :) [13:02:59 CEST] <LongChair> jkqxz: i'll try to make the opengl-interop in mpv do it right when we have settled with something. If you still play with vaapi then you could probably have it render the frames with drm overlay [13:03:31 CEST] <LongChair> i don't want that interop to be rockchip specific [13:03:49 CEST] <LongChair> just a way to render the AV-PIX-FMT_DRM frames that is as generic as can be [13:06:29 CEST] <LongChair> jkqxz: let's see what wm4 thinks about that :) then we can make a sample v3 :p [13:08:50 CEST] <TMM> If I want to create an AVFrame* do I have to set its size somehow? I have done an av_frame_alloc() on my two scratch buffers, but it seems to not be enough. Makes sense I suppose. [13:09:09 CEST] <TMM> Should I maybe be using just char* buffers for this internally to my codec instead of AVFrames? [13:12:33 CEST] <nevcairiel> you need to create an avframe, fill its size and type, and then fall ff_get_buffer [13:16:05 CEST] <TMM> nevcairiel, is that this av_frame_set_qp_data()? [13:16:14 CEST] <TMM> table* [13:23:26 CEST] <TMM> oh, I see, does ff_get_buffer() actually create a buffer? [13:27:12 CEST] <wm4> jkqxz, LongChair: right, for vaapi you import one image per plane [13:27:23 CEST] <wm4> and each image is mapped as texture [13:27:47 CEST] <wm4> thus you an sample from luma and chroma planes as separate textures [13:37:58 CEST] <TMM> OK: So what I appear to have to do is decode my frames to separate buffers, then only copy blocks that have changed in that buffer to the actually display frames. Filling the entire display frame with what was there previously for blocks that weren't changed. I think I need to have two buffers to do this decoding on, at least that's how I did it in the past. So I was thinking of creating two AVFrame's for this decoding and then swapping th [13:37:58 CEST] <TMM> em, in the final step of frame decoding copying the actual changed blocks. [13:38:03 CEST] <TMM> Does this sound reasonable? [13:38:42 CEST] <wm4> it's an obscure game format, so whatever works [13:39:21 CEST] <TMM> well, I'd like to see this merged eventually :) [13:42:51 CEST] <TMM> I'm also not entirely sure where I should be allocating the buffers for my 'scratch' AVFrames, ipvideo_decode_init probably, but I don't know if I have the information there yet required to do so [13:44:24 CEST] <atomnuker> wait until you get a packet and then allocate it (or reallocate it if the format changes) [13:44:46 CEST] <atomnuker> all decoders should be able to deal with changing pixel formats, widths, everything [13:45:22 CEST] <atomnuker> though you could probably rely that those old game formats won't change anything during runtime [13:46:31 CEST] <TMM> they can actually change resolution [13:46:44 CEST] <TMM> but ffmpeg currently doesn't support that for MVE [13:47:38 CEST] <BBB> wm4: I dont disagree that most of that stuff is marketing bs, but my point was that theres a lot of people that willingly believe it because they dont know any better (see that ubuntu post) [13:47:40 CEST] <TMM> maybe I'll just implement it without supporting these changes now, then made a separate patch to support that feature for all formats [13:47:47 CEST] <BBB> wm4: I used to be in that group also, mind you [13:48:15 CEST] <BBB> wm4: there was a whole group of us that *was* interested in codecs and we had come up with ideas to implement popular codecs outside of ffmpeg so that we wouldnt rely on crap software (no really!) [13:48:24 CEST] <BBB> of course that never worked out (pheew) [13:48:56 CEST] <wm4> BBB: well if all you want is a light third party dependency, then ffmpeg is the worst you could get [13:49:12 CEST] <wm4> because ffmpeg is monolithic, big, and with a cazy and fast changing API [13:49:18 CEST] <BBB> I think we need some positive PR work on our end to make their view of us more favourable, or at least make them willing to investigate before they assume blatantly false allegations as facts [13:49:30 CEST] <BBB> right, and gstreamers api never changes [13:49:31 CEST] <wm4> (the latter part is probably getting better) [13:49:44 CEST] <wm4> BBB: is that irony or not? [13:52:25 CEST] <wm4> I mean I heard gst's API was very stable [13:52:34 CEST] <wm4> having not changed ABI for a decade etc. [13:52:56 CEST] <TMM> atomnuker, can you tell me what api I should use to create that buffer? I found some references to av_picture_fill and avpicture_get_size() but the doxygen suggests I should be using an AVBuffer api? [13:55:44 CEST] <atomnuker> TMM: ff_get_buffer [13:56:15 CEST] <TMM> oh, so that does create the buffer? I was confused [13:56:30 CEST] <TMM> will that also fill in things like the linesize etc? [13:57:06 CEST] <atomnuker> yes [13:57:56 CEST] <TMM> ok, thanks, sorry for misunderstanding you nevcairiel [14:15:32 CEST] <TMM> atomnuker, do I need to separate free that buffer or will av_frame_free() take care of that? [14:16:16 CEST] <atomnuker> I don't think you understand how decode_frame works [14:16:30 CEST] <atomnuker> you get an empty unallocated frame in the void pointer [14:16:49 CEST] <atomnuker> you cast the pointer to an avframe [14:17:04 CEST] <atomnuker> it points to some outside frame but is empty [14:17:15 CEST] <atomnuker> ff_get_buffer fills it and allocates the buffers [14:17:23 CEST] <atomnuker> and then you draw to it [14:17:55 CEST] <atomnuker> you don't free it before you return, something else frees it, the decoder only allocates and draws to it [14:18:25 CEST] <atomnuker> now, if you want to allocate another frame, you can do that again using the ff_get_buffer function [14:18:47 CEST] <atomnuker> though you'll own it so you'll need to free it (during deinit since you'll need it) [14:19:03 CEST] <TMM> I need to keep two frames for internal decoding purposes that never get freed until after the entire movie is done [14:19:30 CEST] <atomnuker> yep, go ahead and do that on the first frame and call av_frame_free during deinit [14:20:16 CEST] <atomnuker> put error checking to make sure the allocated width and height still match the width and height on each frame [14:20:27 CEST] <nevcairiel> didnt you say you just need the last frame, why is it two now [14:21:02 CEST] <nevcairiel> we have plenty simple codecs that reference the last frame in the decoder, you could look at one of those [14:21:17 CEST] <atomnuker> (keep in mind you can technically avoid allocation of extra frames if you can reuse the first frames by reffing the frames you are given) [14:21:41 CEST] <TMM> nevcairiel, this codec doesn't do that, it needs to refer to an 8x8 pixel block since before the last time it was changed, an arbitrary amount of time in the past [14:21:59 CEST] <nevcairiel> well thats still one frame [14:23:20 CEST] <TMM> This is the function I currently have that does the right thing now: https://github.com/hpvb/FFmpeg/commit/21aa37ae8326a09a72e44ab9352f60e4439f0… [14:24:01 CEST] <TMM> the relevant bits for what I now do with those two extra frames is here : https://github.com/hpvb/FFmpeg/commit/21aa37ae8326a09a72e44ab9352f60e4439f0… [14:25:13 CEST] <TMM> And this is where I need to get data from prior to the last time a particular block was changed: https://github.com/hpvb/FFmpeg/commit/21aa37ae8326a09a72e44ab9352f60e4439f0… [14:35:30 CEST] <BBB> wm4: it was irony, because when they add hw support, they also need api additions [14:35:43 CEST] <BBB> wm4: its not that the gstreamer stamp suddenly makes everything magical [14:35:54 CEST] <BBB> youre still subject to reality and so on [14:36:41 CEST] <nevcairiel> but it so does! [14:37:31 CEST] <nevcairiel> for reasons the foss people really like gstreamer, even though its just an ugly wrapper around all the things they dont like =p [14:38:03 CEST] <BBB> I think we should stop them disliking us [14:38:12 CEST] <BBB> they dislike us for reasons that have little to do with technology [14:38:15 CEST] <BBB> these are all just side-effects [14:38:25 CEST] <BBB> they dislike our api because they dislike us, its like partisan politics [14:38:36 CEST] <wm4> BBB: I don't know the gst API, the only time I tried it it fucked with my head and I didn't get it [14:38:38 CEST] <BBB> they also dislike our implementations and our hardware support because they dislike us [14:38:43 CEST] <BBB> the fundamental issue is that they dislike us [14:38:48 CEST] <BBB> we can fix the disliking us [14:38:54 CEST] <BBB> then they will like our api better also [14:38:56 CEST] <BBB> and our hw [14:38:58 CEST] <BBB> and everything else [14:38:58 CEST] <nevcairiel> maybe they should just stop being petty [14:39:03 CEST] <BBB> ... [14:39:08 CEST] <wm4> on the other hand I think the ffmpeg API is quite simple now (although obscure things still might steal attention and energy from new users, so that should be fixed) [14:39:10 CEST] <BBB> yes and libav/ffmpeg is all libavs fault [14:39:19 CEST] <BBB> that will surely fix everything [14:39:36 CEST] <BBB> wm4: if you know gst, gst api is quite simple [14:39:36 CEST] <wm4> who mentioned libav [14:39:41 CEST] <BBB> wm4: if you know ffmpeg, ff api is quite simple [14:39:44 CEST] <BBB> but theyre different [14:39:45 CEST] <wm4> <nevcairiel> for reasons the foss people really like gstreamer, even though its just an ugly wrapper around all the things they dont like =p <- like dshow on windows? trollol [14:39:51 CEST] <BBB> so if you know and expect ffmpeg, gst api is crazy [14:39:56 CEST] <BBB> and if you know and expect gst, ff api is crazy [14:40:05 CEST] <wm4> that was at a time when I didn't know ffmpeg well [14:40:15 CEST] <BBB> my point is we should stop hating them and should try to get them to stop hating us [14:40:21 CEST] <BBB> for example by being nice [14:40:33 CEST] <wm4> (and I was quite afraid of ffmpeg first, I didn't know if I could keep up with my mplayer2 fork) [14:40:35 CEST] <nevcairiel> when i first got into ffmpeg, i didnt find the api very hard, and that was in a time when it was still much worse then it is today [14:40:57 CEST] <wm4> maybe it's because dshow is so much more crazy [14:40:59 CEST] <BBB> nevcairiel: did you start before it worked on msvc? [14:41:03 CEST] <nevcairiel> yes [14:41:05 CEST] <nevcairiel> much before that [14:41:07 CEST] <BBB> omg poor you [14:41:18 CEST] <BBB> pre-fork? [14:41:22 CEST] <nevcairiel> yea [14:41:28 CEST] <nevcairiel> i started in like 2010 [14:41:33 CEST] <BBB> yeah youve seen everything then [14:41:56 CEST] <wm4> also our API example are all shitty and confusing [14:42:07 CEST] <BBB> they are indeed [14:42:52 CEST] <nevcairiel> well the problem with examples is that all the things are rather inter-twined, to demonstrate decoding you also need to involve avformat, because you want something that actually works [14:43:20 CEST] <nevcairiel> so small self-contained examples is hard [14:51:32 CEST] <BBB> J_Darnley: Im looking at wmv1 now, a quick test suggests that its related to inter block coding? [14:51:40 CEST] <BBB> Im not 100% sure how yet [14:51:48 CEST] <BBB> but they keyframe is identical [14:54:43 CEST] <iive> I've always thought that others dislike using ffmpeg api, because it breaks/changes so much [14:55:22 CEST] <iive> and that was even pre-fork. e.g. ffms [14:55:57 CEST] <nevcairiel> well its not like we change it for fun, but because the design was limiting serious improvements [14:56:49 CEST] <iive> well, renaming labels, variables, moving stuff around... [14:57:45 CEST] <iive> or e.g. removing a single fixed quant variable and replacing it with additional array that contains the quant for a given range.... yeh, that's much simpler [15:02:00 CEST] <jkqxz> LongChair: wm4: <http://sprunge.us/CRhE> [15:02:45 CEST] <jkqxz> Mainly the header changed: more comments on everything. [15:04:04 CEST] <jkqxz> How big should the arrays be? The EGL extension limits you to four planes per image, and you can't really have more images or object than real planes. [15:06:02 CEST] <jkqxz> I think it's unnecessary to actually do the allocation setup at this point - if there is a non-testing use-case for it then it can be added later without an ABI change, because AVHWFramesContext.hwctx is expandable. [15:10:22 CEST] <wm4> ugh nested static arrays [15:10:46 CEST] <jkqxz> Would you prefer them to be named structures? I wondered about that, but they don't have any external use at all. [15:10:48 CEST] <wm4> next iteration you should also get rid of the nested anonymous struct definitions, and define them separately [15:11:31 CEST] <kierank> BBB/J_Darnley: did you end up resolving the issues [15:11:36 CEST] <wm4> do we expect that there are cases where you have multiple images, and each image can have more than 1 plane? [15:11:45 CEST] <BBB> kierank: mdec is fixed, Im looking at wmv1 now [15:11:57 CEST] <kierank> ok [15:11:59 CEST] <wm4> as opposed to 1 "merged" image for all planes vs. 1 image per plane [15:12:07 CEST] <kierank> amazing what a leviathan this idct is [15:12:40 CEST] <jkqxz> NV12A in NV12-is-one-image-land? [15:12:50 CEST] <BBB> kierank: :-p [15:12:58 CEST] <wm4> jkqxz: never heard of this NV12A? [15:13:19 CEST] <nevcairiel> it seems fascinating that the idct which should be a rather generic component can apparently cause single issues in odd codecs [15:13:31 CEST] <jkqxz> I mean, NV12 + A. [15:13:40 CEST] <jkqxz> Is that a thing? [15:13:40 CEST] <wm4> jkqxz: does anything use it? [15:13:43 CEST] <BBB> michaelni: how is the permutation for the fdct set? what I mean is, how do we ensure that the permutation of the fdct output and idct input is identical? [15:13:51 CEST] <BBB> michaelni: or where does the conversion between them take place? [15:14:03 CEST] <jkqxz> No idea, I'm just trying to think of ways that people writing drivers could screw over anything but the most general representation :P [15:15:33 CEST] <wm4> jkqxz: I'm fine with assuming this won't happen for now [15:15:51 CEST] <wm4> I'm thinking that this would make it slightly easier, but maybe I'm wrong [15:18:02 CEST] <jkqxz> A top level flag for "planes are all in one image"? (If set, use the format on the first one and combine all of the planes.) [15:19:45 CEST] <wm4> or maybe an array of 4 planes, and each plane has a flag whether it starts a new image? [15:19:58 CEST] <jkqxz> I guess you don't need that if you know separately how many planes are in each format (e.g. NV12 -> 2). [15:19:59 CEST] <wm4> ok maybe that's all worse than having a 4x4 nested array [15:20:10 CEST] <wm4> hm not sure [15:20:29 CEST] <wm4> don't you still need to tell EGL/DRM the offset and stride of each plane? [15:21:30 CEST] <jkqxz> Yes. You'd see a DRM_FORMAT_NV12 plane and know that you have to combine it into one image with the next one. [15:32:46 CEST] <TMM> Is there a frame number somewhere? I have to skip a particular operation only on the very first frame [15:33:34 CEST] <BBB> kierank: making slow progress, the block that starts the mismatch is at mb_x=13, mb_y=0, frame=1, block=3 [15:33:54 CEST] <BBB> kierank: it appears that the noise shaping did something different [15:34:18 CEST] <BBB> Im suspecting that it may not be aware of wmv1 scantable specifics (theyre different from mpeg1/msmpeg4v12) [15:34:23 CEST] <BBB> or something like that [15:35:03 CEST] <kierank> cool, thanks for spending time on this [15:37:20 CEST] <BBB> kierank: and the diff comes from round [15:37:23 CEST] <BBB> err [15:37:23 CEST] <BBB> quant [15:38:46 CEST] <BBB> what the hell, input to quant is also different [15:38:56 CEST] <BBB> hm.. [15:41:19 CEST] <TMM> I just posted my patch to ffmpeg-devel, I hope I didn't mess it up too badly :) [15:54:15 CEST] <atomnuker> TMM: avctx->frame_number [16:05:39 CEST] <BBB> michaelni: at this point I probably need help; I have identical commandlines with -idct simple or without (to force the C idct or the SSE2 one we wrote); otherwise no cpuflags and all bitexact flags are set [16:06:17 CEST] <BBB> michaelni: at frame: 1, mb_x: 4, mb_y: 0, b: 0, intra: 0, mv_dir: 1, mv: 0, -4 (with or without -idct simple) [16:06:34 CEST] <BBB> michaelni: the residual (from diff_pixels()) is different [16:06:35 CEST] <BBB> michaelni: why? [16:06:58 CEST] <BBB> michaelni: until then, everything is the same, and assuming that the reference is the keyframe, the encoding of the keyframe itself is identical [16:07:17 CEST] <BBB> michaelni: so & why is the predictor different? is stuff there dependent on idct variables? [16:13:41 CEST] <TMM> atomnuker, that did it, thank you! [16:14:17 CEST] <iive> BBB: j-frames (intra x8) are not involved in these tests, are there? [16:14:43 CEST] <atomnuker> J_Darnley: in hindsight, I'm not sure that strip -x patch was a good idea [16:15:24 CEST] <atomnuker> the text and comments are also stripped so you're left with just instructions [16:15:47 CEST] <atomnuker> it looks tidier but it takes a bit longer to look up which instruction goes where if you have many similar [16:31:38 CEST] <LongChair> jkqxz, wm4: ok saw the last version, are we happy with that one ? [16:32:56 CEST] <wm4> not sure [16:33:11 CEST] <wm4> I'm slightly unhappy with the nested array, that makes for 256 inner entries [16:36:22 CEST] <michaelni> BBB for your first question, i think we permute to the idct order in dct quantize [16:38:47 CEST] <michaelni> for the 2nd question i dont know, the idct can used in the decission which mb coding mode to use and such though when thats enabled [16:41:30 CEST] <jkqxz> AV_NUM_DATA_POINTERS is 8. [16:41:47 CEST] <jkqxz> I think 4 would probably be ok there. [16:46:46 CEST] <LongChair> i think wm4 means he would like something like AVDRMFrameDescriptorObject, AVDRMFrameDescriptorImage and AVDRMFrameDescriptorPlane separately :) [16:50:12 CEST] <wm4> that too [16:50:23 CEST] <wm4> jkqxz: oh, well, still makes 64 [17:02:46 CEST] <J_Darnley> atomnuker: that's a shame [17:03:40 CEST] <J_Darnley> What takes more time? Did you mean human work or some program? [17:04:36 CEST] Action: J_Darnley wonders where he left mp3gain [17:06:29 CEST] <atomnuker> more human work to figure out, yet not because the printout looks more tidy rather than <comment>\n<instruction>\n<comment> etc. [17:08:03 CEST] <J_Darnley> I don't think I've ever seen that. Perhaps gdb and objdump are too dumb for that [17:08:45 CEST] <J_Darnley> if you want to revert I won't object [17:10:54 CEST] <atomnuker> this happens in perf [17:11:08 CEST] <atomnuker> nah, its fine, I don't mind it [17:24:10 CEST] <atomnuker> J_Darnley: can you test that -X does what you preferred? [17:24:42 CEST] <atomnuker> it leaves comments and globals but apparently removes compiler generated symbols (like loops) [17:25:15 CEST] <atomnuker> just replace check_stripflags -x with check_stripflags -X in configure [17:29:05 CEST] <Gramner> -X doesn't strip things like function_name.loop [17:29:16 CEST] <Gramner> which -x does [17:53:00 CEST] <BBB> I think which flag you want depends on what your goal is [17:53:04 CEST] <BBB> -X is better for perf output [17:53:11 CEST] <BBB> -x [17:53:13 CEST] <BBB> I mean [17:53:20 CEST] <BBB> -X is better for debugging, where you want to know loop markers [18:21:02 CEST] <LongChair> jkqxz: any other proposal ? :) [18:38:32 CEST] <philipl> BtbN jkqxz wm4: https://github.com/philipl/FFmpeg/commit/472d5a58d3676b2c906c10bab04484a511… [18:38:52 CEST] <philipl> Trying to introduce a new ffmpeg hwaccel type so we can deprecate cuvid properly, but it's not working. [18:56:43 CEST] <jkqxz> <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg.c;h=6170bd453cb8ec421…> [18:56:59 CEST] <jkqxz> Two hwaccels with the same pixfmt does not work so well. [19:06:02 CEST] <wm4> right, you somehow need to block get_format [19:18:25 CEST] <philipl> sad panda. [19:18:46 CEST] <philipl> So, can we look at a strategy to specify the default output format for the hwaccel? [19:20:45 CEST] <wm4> you mean cuda specifically defaulting to a different output format? [19:20:53 CEST] <philipl> Yeah [19:21:44 CEST] <philipl> make the default format part of the hwaccel definition in ffmpeg_opt.c [19:26:10 CEST] <wm4> that would lead to a messy difference between cuda and everything else that we'd never get rid of [19:26:17 CEST] <wm4> (wait, why is cuda different in the first place?) [19:26:43 CEST] <wm4> maybe we could just deprecate _not_ using hwaccel_output_format? [19:26:51 CEST] <philipl> We could. [19:27:02 CEST] <philipl> Or why not treat the hwaccel's pix_fmt as the default to begin with? [19:27:13 CEST] <philipl> Isn't that actually what most people want? [19:27:28 CEST] <philipl> If they're using 'ffmpeg' and hwaccel, they are probably trying to do a full hardware transcode [19:31:42 CEST] <wm4> philipl: I don't know, isn't the argument compatibility? so changing everything to either behavior is a breakage [19:32:23 CEST] <philipl> Isn't hwaccel_output_format new in the set of changes that jkqxz pushed? We haven't released anything with it yet. [19:33:23 CEST] <wm4> ah [19:33:35 CEST] <wm4> so for e.g. vaapi, did the default change? [19:34:07 CEST] <philipl> Yeah. I don't know. Presumably, ffmpeg didn't even work with vaapi before, so maybe that's a bad example. [19:34:09 CEST] <philipl> What about vdpau? [19:36:05 CEST] <jkqxz> The -hwaccel_output_format option has been there for VAAPI since it was first added last year. Before the recent change, VDPAU and DXVA2 would always download and there was no way to tell it not to. [19:36:12 CEST] <jkqxz> No defaults have changed. [19:37:09 CEST] <nevcairiel> (also no reason not to, since nothing could really do anything with dxva2 frames) [19:37:09 CEST] <jkqxz> Well, DXVA2 will once that gets merged here. [19:37:24 CEST] <jkqxz> Yeah, but we want to change that! [19:37:54 CEST] <philipl> https://github.com/philipl/FFmpeg/commit/453c4d8dd9cb0e9ed2ac594d05420a34f4… [19:37:57 CEST] <philipl> That's my idea. [19:38:07 CEST] <philipl> just make the default be the native hwaccel format [19:38:40 CEST] <nevcairiel> the question is if that automatically works with any sort of software processing transparently [19:39:01 CEST] <jkqxz> No, you will need hwdownload if you have that. [19:39:07 CEST] <atomnuker> jamrial: I'm getting illegal hardware instruction on fmaddps, and I'm running on a skylake [19:39:10 CEST] <philipl> yeah. it won't magically work. [19:39:13 CEST] <nevcairiel> because previously you could just set -hwaccel dxva2 and it would just work [19:39:15 CEST] <atomnuker> is there something special I need to do to use fma? [19:39:27 CEST] <nevcairiel> hardware decoder, no further limitations [19:39:40 CEST] <wm4> so cuda was always the different one [19:39:44 CEST] <jkqxz> Yeah, I'm dubious about the compatibility change. [19:39:57 CEST] <philipl> wm4: So, then we add a flag to the hwaccel entry saying whether the native format is default or not. [19:40:19 CEST] <nevcairiel> personally i think it would probably be best if they all behave the same [19:40:22 CEST] <jkqxz> Not really, it's different because it's not a real hwaccel at all. QSV similarly - you would get hardware surface output if you set hwaccel and not if not. [19:41:07 CEST] <LongChair> jkqxz, wm4: so do we settle on something for that hwcontext_drm ? is all we need to split the AVDRMFrameDescriptor sub structs in other individual structs or do we need more changes ? [19:41:59 CEST] <wm4> I'm still not convinced we need to support the case of multiple planes per image + multiple images [19:42:17 CEST] <wm4> just leads to complexity with generic code trying to handle that [19:43:14 CEST] <LongChair> ok, jkqxz: thoughts ? [19:43:15 CEST] <jkqxz> philipl: I think that change would be ok. The default_pix_fmt for everything except cuvid would presumably be NONE? [19:43:36 CEST] <wm4> philipl: so did "ffmpeg -hwaccel cuvid -i file.mkv ..." actually work and use the cuda format? [19:43:42 CEST] <jkqxz> wm4: Would you prefer a one-dimensional array with markers saying where the image boundaries are, then? [19:43:51 CEST] <wm4> jkqxz: hm, maybe [19:44:00 CEST] <philipl> wm4: with my default change, it worked. [19:44:15 CEST] <wm4> jkqxz: but that would be semantically the same, and a nested array might be better [19:44:38 CEST] <wm4> jkqxz: (probably still could #define AV_DRM_PLANES 4, instead of using AV_NUM_DATA_POINTERS) [19:45:02 CEST] <wm4> philipl: does that mean -hwaccel magically forces the correct codec? [19:45:03 CEST] <jkqxz> Yeah, I'm pretty sure 4 is good. [19:45:28 CEST] <philipl> jkqxz: https://github.com/philipl/FFmpeg/commit/e4772ef21eb148f54076e5ff9b9be0f5b2… [19:45:30 CEST] <jamrial> atomnuker: make sure you're using fmaddps (a macro), not vfmaddps (a fma4 instruction) [19:45:40 CEST] <philipl> wm4: If we tell it to force it, then it does. [19:45:57 CEST] <wm4> philipl: not following here [19:46:11 CEST] <philipl> wm4: Ok, maybe I misunderstood your question. [19:46:26 CEST] <philipl> Today, '-hwaccel cuvid' forces the native cuda format. [19:46:37 CEST] <philipl> When people don't want that they don't specify the hwaccel. [19:47:04 CEST] <philipl> To achieve the same behaviour with generic hwaccel, I need to override the output format automatically. [19:47:16 CEST] <philipl> My latest suggestion is a per-hwaccel flag that says whether to override to the native format or not. [19:47:21 CEST] <jkqxz> philipl: That change mixes the two? (Also please don't shout your booleans.) [19:47:26 CEST] <philipl> and we set it to true for cuda, and maybe for qsv but not for anything else. [19:47:38 CEST] <wm4> philipl: I'm talking about the codec [19:48:04 CEST] <wm4> since the default codec will be "h264" which doesn't support cuda, you need "h264_cuvid" [19:48:08 CEST] <philipl> jkqxz: don't shout booleans? We use uppercase normally, I thought. [19:48:36 CEST] <philipl> wm4: if you specify the codec without the hwaccel, you get a software format [19:49:08 CEST] <wm4> and if you specify the hwaccel without codec? (that has been my question for the last 5 minutes) [19:49:21 CEST] <philipl> I think it blows up. hang on. [19:50:34 CEST] <philipl> wm4: it just ignores it, because it's not a real hwaccel. [19:50:43 CEST] <philipl> the default software decoder and encoder get used. [19:51:12 CEST] <wm4> ok [19:51:50 CEST] <wm4> that must be quite confusing for users [19:52:05 CEST] <philipl> I'm not sure what they experience, honestly :-) [19:52:10 CEST] <philipl> So what happens today: [19:52:20 CEST] <wm4> so I'd say this is all lost, and we should at least make them all behave the same [19:52:35 CEST] <wm4> that means, requiring -hwaccel_output_format for cuda [19:52:44 CEST] <philipl> 1) If you don't specify '-hwaccel cuvid' and try to use cuvid/nvenc, they will use the hardware with download/upload in between. [19:53:01 CEST] <philipl> 2) if you do specify '-hwaccel cuvid' and use cuvid without nvenc, it blows up with format mismatch [19:53:21 CEST] <wm4> wut [19:53:22 CEST] <philipl> 3) If you specify -hwaccel cuvid without cuvid/nvenc, it's just ignored. [19:53:47 CEST] <philipl> 2a) If you use hw_download, it works too [19:54:11 CEST] <nevcairiel> the cuvid and qsv cases have been all sorts of fucked up [19:54:43 CEST] <wm4> but 2) shouldn't happen with the new behavior [19:54:44 CEST] <atomnuker> jamrial: yep, using the macro (can you configure the macro like the instruction e.g. 123 or 321?) [19:54:46 CEST] <nevcairiel> imho -hwaccel cuvid should do a simple thing: make ffmpeg.c somehow pick the cuvid decoders over the other decoders, if available, and nothign else [19:55:03 CEST] <wm4> nevcairiel: that would be a higher level thing [19:55:05 CEST] <nevcairiel> that would make it behave just like -hwaccel dxva2 or such [19:55:17 CEST] <wm4> (but agreed) [19:55:35 CEST] <wm4> that would require an API extension as far as I'm aware [19:55:44 CEST] <nevcairiel> name matching, yo [19:55:48 CEST] <wm4> (there's nothing that tells it which decoder is a cuvid h264 decoder etc.) [19:55:59 CEST] <wm4> name matching is what I do in mpv, and it makes me cry [19:56:29 CEST] <philipl> wm4: 2) doesn't happen with new generic hwaccel, but the primary case (use hwaccel, specify cuvid and nvenc) stops using full hardware transcoding. [19:56:47 CEST] <wm4> philipl: so the user needs to add that flag [19:56:50 CEST] <wm4> where's the problem [19:57:27 CEST] <wm4> ffmpeg.c hwaccel is rather low level, so it reflects to how it's used [19:57:55 CEST] <wm4> you need to decide and choose your filters whether to handle hwaccel or sw formats etc. [19:57:56 CEST] <jamrial> atomnuker: the macro chooses the correct fma3 instruction for you [19:59:18 CEST] <philipl> Today, 'hwaccel cuvid' is the way you ask for full transcoding. That's the issue. [19:59:18 CEST] <philipl> If we switch to generic hwaccel, it stops working [19:59:18 CEST] <philipl> command line comaptibility breaks [19:59:18 CEST] <philipl> old command line stops doing what it used to do [19:59:19 CEST] <philipl> BtbN: said he thought that was a problem in the email thread [19:59:19 CEST] <atomnuker> how does it know which numbers I want to add and multiply? [20:00:07 CEST] <philipl> I have to run. Maybe BtbN will chime in at some point. I'll try and catch up later. [20:04:22 CEST] <nevcairiel> atomnuker: you specify it in fma4 syntax and it figures it out [20:04:54 CEST] <nevcairiel> it choses the appropriate instruction based on which parameters are memory arguments, if any [20:08:01 CEST] <atomnuker> wtf, it was crashing because I used INIT_XMM fma4 [20:08:21 CEST] <atomnuker> I thought fma4 was a superset of fma3 as well [20:08:36 CEST] <nevcairiel> no, they are competing techs, fma3 is intel, fma4 is amd [20:09:16 CEST] <atomnuker> ... [20:09:25 CEST] <nevcairiel> although amd started supporting fma3 as well now [20:09:58 CEST] <nevcairiel> amd ryzen actually dropped fma4, afaik [20:10:17 CEST] <nevcairiel> or it was just broken adn therefor disabled [20:10:18 CEST] <nevcairiel> one of those [20:10:24 CEST] <jamrial> it wasn't broken [20:10:46 CEST] <jamrial> they officially dropped it for ryzen, yes, but it apparently still work :p [20:10:56 CEST] <jamrial> at least according to agner's pdf [20:11:32 CEST] <jamrial> the history of fma3/4 is fun. good example of lack of communication i guess [20:13:24 CEST] <jamrial> xop seems to be gone for good in ryzen [20:13:42 CEST] <nevcairiel> no point in keeping those, with intels dominance noone optimizes for those [20:16:27 CEST] <atomnuker> fmaddps fails if the first register is less than m5 [20:16:40 CEST] <atomnuker> this is some messed up macro [20:17:00 CEST] <atomnuker> (e.g. fma3 emulation of ``fmaddps xmm4, xmm3, xmm2, xmm5'' is not supported) [20:17:20 CEST] <nevcairiel> fma3 only supports 3 registers, so your dst needs to be identical to one of your sources [20:18:01 CEST] <atomnuker> oh, so that's why fma4 compiled correctly [20:19:32 CEST] <jamrial> if you use four different regs in a function targetting fma3, it should warn you [20:19:46 CEST] <nevcairiel> well, it'll error on you [20:19:49 CEST] <nevcairiel> ie. an advanced warning [20:19:49 CEST] <nevcairiel> :D [20:21:07 CEST] <TMM> "While the FMA4 instructions seem to work according to some tests, they can also give wrong results.[16]" [20:21:09 CEST] <TMM> fun [20:23:51 CEST] <jamrial> is that on ryzen? [20:24:59 CEST] <TMM> yeah [20:25:25 CEST] <TMM> apparently they dropped support for it late in the release process and they didn't want to patch the instruction decoder [20:25:38 CEST] <TMM> so ryzen doesn't signal FMA4 in CPUID, but it doesn't trap [20:25:47 CEST] <TMM> it just returns garbage, on some insns [20:25:50 CEST] <TMM> that's real fun [20:26:07 CEST] <nevcairiel> well not really [20:26:11 CEST] <nevcairiel> if you use it without cpuid [20:26:13 CEST] <nevcairiel> its your own fault [20:26:19 CEST] <atomnuker> well, fma does increase inaccuracies slightly [20:26:40 CEST] <TMM> well, sure, you're not supposed to use features not in cpuid, but don't processors normally trap? [20:27:13 CEST] <TMM> I don't know if people use the trapping behavior for feature detection instead of cpuid maybe [20:30:06 CEST] <nevcairiel> i suppose, but it would seem stupid to do that if there is a feature reporting mechanism [21:07:04 CEST] <TMM> I'm looking at why MVE movie playback doesn't exit, the AVInputFormat .read_packet returns AVERROR(EIO), this is apparently not enough to end the decoding. Does the codec have to do something too? [21:28:39 CEST] <TMM> oh, ffplay also doesn't end on avis it seems [21:30:28 CEST] <TMM> There actually was a bug with that :) It always returned 'invalid data' at the end of an MVE, I fixed htat at least [21:30:39 CEST] <TMM> but is ffplay supposed to exit at the end of a file? [21:31:01 CEST] <TMM> ffplay from fedora packages also doesn't seem to exit, weird [21:37:23 CEST] <nevcairiel> ffplay doesnt exist on its own unless you specify -autoexit i think [21:46:10 CEST] <TMM> ah [21:48:03 CEST] <TMM> nevcairiel, that did it :) also now I can verify that my codec is actually not so broken [22:17:21 CEST] <cone-823> ffmpeg 03James Almer 07master:8ddb6820bd52: avformat/libssh: check the user provided a password before trying to use it [22:24:52 CEST] <atomnuker> jamrial / nevcairiel: how do I replace vfmaddsub123ps m3, m2, m1 with fmaddsubps? [22:25:19 CEST] <atomnuker> all permutations of the 4 registers yield completely wrong results to what I need [22:25:57 CEST] <jamrial> atomnuker: fma* dst, src1, src2, src3 ---> dst = src1 * src2 + src3 [22:26:38 CEST] <TMM> Hmm, there's one more feature missing in ffmpeg for MVE support it seems. MVE has this notion of a 'display op' which is what will make the current front buffer actually render to screen. Currently ffmpeg renders each display frame to the output [22:26:43 CEST] <jamrial> dst needs to be the same as one of the three src regs for it to work with fma3 [22:27:21 CEST] <TMM> does ffmpeg natively have a feature for this? Or do I have to implement 'offscreen' rending the the codec and pass whether or not whatever is currently on the front buffer be actually displayed or not? [22:27:30 CEST] <nevcairiel> 123 isnt even a valid suffix, is it [22:29:12 CEST] <atomnuker> it compiles and runs fine [22:31:38 CEST] <nevcairiel> all the intel docs i see only reference 132, 213 or 231 [22:32:05 CEST] <TMM> I think I basically need to be calling my codec repeatedly without necessarily creating an actual frame [22:32:59 CEST] <atomnuker> how come it runs then? [22:33:42 CEST] <jamrial> "error: undefined symbol `vfmaddps123.loop'" [22:33:48 CEST] <jamrial> 123 doesn't even assemble for me [22:34:27 CEST] <jamrial> atomnuker: in any case, it's not hard. just use fm{add,sub,etc} dst, src1, src2, src3 and forget about all the crazy numbers and crap from fma3 [22:34:39 CEST] <jamrial> the macros will figure that out for you [22:35:23 CEST] <nevcairiel> vfmaddsub132ps m3, m2, m1 would become fmaddsubps m3, m3, m1, m2 anyway [22:35:43 CEST] <atomnuker> oh crap, I thought my dst was m1 [22:36:05 CEST] <atomnuker> (because I wanted to use it in another part of the code but there the dst was m1) [22:36:46 CEST] <atomnuker> yep, everything is fine now [22:36:59 CEST] <nevcairiel> if you need to translate existing fma3 code to fma4/x86inc, you can a ctually use the numbers to permute the arguments [22:37:18 CEST] <nevcairiel> 132 -> swap second and third argument [22:38:34 CEST] <cone-823> ffmpeg 03Michael Niedermayer 07master:c94326c1fc2f: avcodec/hevcpred_template: Fix left shift of negative value [22:38:35 CEST] <cone-823> ffmpeg 03Michael Niedermayer 07master:c746f92a8e03: avcodec/jpeg2000dsp: Reorder operations in ict_int() to avoid 2 integer overflows [22:38:36 CEST] <cone-823> ffmpeg 03Daniel Kucera 07master:d4a900fad8b1: libavformat/subfile: return AVERROR_EOF on EOF [22:38:37 CEST] <cone-823> ffmpeg 03Daniel Kucera 07master:c557718bea35: libavformat/file: return AVERROR_EOF on EOF [22:38:50 CEST] <nevcairiel> and because the order of multiplications makes no difference, not even all combinations have to exist for fma3 [22:38:54 CEST] <nevcairiel> hence 123 is not a thing [22:39:39 CEST] <jamrial> sucks that fma3 ended up winning in the end [22:39:46 CEST] <jamrial> intel goes and introduces avx with the big change of adding non-destructive versions of existing instructions, then goes and adopts fma3 [22:40:38 CEST] <nevcairiel> i guess they didnt make non-destructive avx versions of fma3 in the process? :p [22:40:44 CEST] <nevcairiel> well that would've kinda been fma4 just weirder [22:41:21 CEST] <nevcairiel> fma4 is also more flexible with using memory inputs, it can actually take two, not just one [22:41:32 CEST] <jamrial> it can? [22:42:40 CEST] <jamrial> yasm doesn't seem to like it [22:43:13 CEST] <nevcairiel> maybe it can just take the memory input in two different locations instead of just the last one like fma3, and the docs werent very explicit [22:43:33 CEST] <jamrial> yes, that it can [22:43:36 CEST] <nevcairiel> (thats really the reason why fma3 has the different permuations anyway, so different arguments can be memory) [22:43:40 CEST] <jamrial> either in the third or four operand [22:45:40 CEST] <TMM> Is it actually ok to not emit a new frame when decode() is called? [22:47:10 CEST] <TMM> I guess I'll have to queue op video data until I see a decode op actually, and just run it in the codec, judging by the apis [22:47:37 CEST] <atomnuker> TMM: yep, just set *got_frame to 0 and return a 0 [22:48:14 CEST] <TMM> oh, that's not as painful as I'd feared then [22:49:20 CEST] <Gramner> you cannot really encode multiple memory operands in x86 anyway, not without inventing a new instruction encoding that isn't even similar to the existing ModR/M stuff which would add a ton of decoder complexity [22:52:16 CEST] <Gramner> also fma4 is essentially two separate instructions since either the multiplier or the addend can be memory [22:52:35 CEST] <Gramner> they just happen to have the same instruction name [22:57:39 CEST] <Gramner> intel's implementation of vex couldn't really handle more than 3 registers in a sensible way, see vpblendvb for a fun example of hackery required to accomplish 4-arg (it encodes one register number as an imm8 and is slower than the non-vex pblendvb on some cpus) [23:01:00 CEST] <Gramner> intel and amd wouild both be better off if they would actually talk to each other about how to handle ISA extensions, but good luck with that [23:11:42 CEST] <TMM> atomnuker, ah, this worked great [23:14:19 CEST] <TMM> maybe I should chop up this patch series and actually try to submit it [23:14:34 CEST] <TMM> I think my request for comment patch may be a little large for anyone to seriously look at [23:25:54 CEST] <nevcairiel> Gramner: well at this point it doesnt seem all that likely that AMD would be inventing many extensions, but who knows [23:26:23 CEST] <Gramner> they're better off not doing that, yeah [23:26:44 CEST] <Gramner> they have a very limited R&D budget, better spend it somewhere more useful [23:30:29 CEST] <Gramner> I wonder what will happen ~2019 when amd's x86-64 patents expire while intel still holds patents for all the new instruction sets [23:30:33 CEST] <nevcairiel> meanwhile, intel and its partners seem to have some pre-launch trouble with Skylake-X, reviewers are a bit annoyed that the BIOSes are a bit unfinished and performance drastically improved just in the last 48 hours, with reviews scheduled to be released on monday... busy weekend [23:31:57 CEST] <jamrial> Gramner: what could happen then? [23:32:11 CEST] <Gramner> who knows? [23:34:20 CEST] <Gramner> I guess anyone should be able to make x86-64 chips by then, albeit without AVX and new stuff like that. dunno if anyone's up for it [23:35:18 CEST] <nevcairiel> its not like any of the non-AMD/Intel chips ever were any good [00:00:00 CEST] --- Sun Jun 18 2017

1 0

ffmpeg.log.20170617
by burek 18 Jun '17

18 Jun '17

[01:19:32 CEST] <postmodern> looking for documentation for various stereo3d settings. trying to combine two webcams into one stereoscopic video. i tried using sbs2l:arcg, but this gives me a portrait sized video, and it seems to favor one webcam over the other. [02:12:25 CEST] <postmodern> ah found the stereo3d documentation. hmm i think i need to somehow combine the two video streams side-by-side then put them through stereo3d [02:27:25 CEST] <postmodern> hmm think i got it working, but getting low fps and "past duration too large" warnings [09:11:09 CEST] <johnjay> hmm [09:11:26 CEST] <johnjay> furq is it bad if when running apt-get upgrade I get an error about unmet dependencies? [12:37:52 CEST] <ChocolateArmpits> Is it possible to use overlay filter or any other filter to have any of the two inputs continue to be output when one of them dies/goes offline ? [12:38:30 CEST] <ChocolateArmpits> Currently overlay only halts the encoding until the one of the inputs is online again [13:47:49 CEST] <noble> hi all, I had some issues with m3u8 downloading using Ffmpeg, i've since come up with a workaround but I was wondering where the best place to report this is so it can be included in the code? Thanks [14:49:10 CEST] <dongs> dong-around [17:16:43 CEST] <ArsenArsen> What options and how do I set on my AVCodecContext to set H264 CRF and preset? [17:42:35 CEST] <DHE> ArsenArsen: when in doubt, you can specify (almost) all ffmpeg command-line args with an AVDictionary. like: av_dict_set(&dictptr, "crf", "21", 0); [17:44:18 CEST] <DHE> which is good because after checking that's necessary for x264 [17:51:13 CEST] <ArsenArsen> So, DHE, arguments equate to dict. variables? [17:53:03 CEST] <DHE> yes. it's intended to allow codec and format specific options but you can specify standard options this way as well [17:53:39 CEST] <ArsenArsen> I see, and I assume Id use `av_opt_set(out->enc->priv_data, <key>, <val>, 0);` to set it? [17:53:57 CEST] <ArsenArsen> I mean, I could use [17:54:23 CEST] <DHE> -f "/mnt/yeti/$package-$id-$name/1080p.m3u8" [17:54:26 CEST] <DHE> oh shit.. [17:54:29 CEST] <DHE> http://ffmpeg.org/doxygen/trunk/group__lavu__dict.html#ga8d9c2de72b310cef8e… [17:54:33 CEST] <DHE> that's the wrong clipboard buffer... [17:54:40 CEST] <ArsenArsen> xD [17:55:12 CEST] <ArsenArsen> Alright, thank you! [17:55:43 CEST] <ArsenArsen> I assume something like 1K would work for variable bitrate [17:56:12 CEST] <DHE> also, http://ffmpeg.org/doxygen/trunk/libavcodec_2options__table_8h_source.html here's the table of "generic" fields accepted by dictionaries for AVCodecContext [17:56:31 CEST] <DHE> for the generics it's also a good way to look up what fields in an AVCodecContext they correspond to [17:58:22 CEST] <ArsenArsen> I'm yet to use dictionaries :) [18:23:57 CEST] <m712> hello [18:24:21 CEST] <m712> it seems like ffmpeg does not insert keyframes when i convert a video to vp9... [18:24:31 CEST] <m712> how can I add keyframes to the output video? [18:25:16 CEST] <kerio> -g [18:25:48 CEST] <m712> i cannot find it documented anywhere, how do I use it? [18:27:54 CEST] <ChocolateArmpits> write a number after that matches the gop length you're after [18:28:06 CEST] <m712> gop length? [18:28:27 CEST] <ChocolateArmpits> each gop starts with a keyframe [18:28:39 CEST] <ChocolateArmpits> so using that you also define the keyframe rate [18:32:54 CEST] <m712> ChocolateArmpits: sorry, i do not know what a "gop" is, can you please give me documentation/tell me what it is? [18:33:50 CEST] <ChocolateArmpits> it's a "group of pictures", a coding method used to cut down on repeating visual portions over a time period [18:34:21 CEST] <m712> i see [18:34:43 CEST] <m712> so -gop 30 means i get a keyframe every 30 "group of pictures" i.e. fames? [18:34:46 CEST] <m712> frames* [18:34:57 CEST] <ChocolateArmpits> yes [18:35:00 CEST] <m712> or rather a gop starts every 30 frames [18:35:05 CEST] <m712> i see [18:35:07 CEST] <m712> thank you [18:35:28 CEST] <ChocolateArmpits> There are several types of frames that are coded in a gop, one of them is I-frames also called keyframes (a term taken from animation) [18:35:38 CEST] <kerio> does a gop *have* to start with a keyframe? [18:35:42 CEST] <m712> what -g value would be appropiate for an 50fps video? [18:35:50 CEST] <m712> i was thinking 50 or 100 [18:35:53 CEST] <kerio> m712: it depends on what you use for streaming [18:36:15 CEST] <ChocolateArmpits> a 2 second gop is most optimal [18:36:15 CEST] <m712> it will be viewed via the browser's default video viewer [18:36:33 CEST] <ChocolateArmpits> Longer gops add latency on playback end [18:37:49 CEST] <m712> i see [18:38:07 CEST] <kerio> never keyframes [18:38:13 CEST] <kerio> intra frame refresh is all you need \o/ [19:26:12 CEST] <buko1911> hey guys, is there a way to increase the attenuation of the lowpass filter ? [19:52:52 CEST] <c3-Win> buko1911: https://ffmpeg.org/ffmpeg-filters.html#lowpass [20:20:54 CEST] <styler2go> Let's say i have a .txt file with some text in each line, can i somehow create a video file which shows one line per one second? [20:28:35 CEST] <ChocolateArmpits> styler2go, look into drawtext filter [20:32:05 CEST] <kerio> styler2go: produce a sequence of images and encode them with ffmpeg maybe? [20:33:00 CEST] <styler2go> hmm good idea, i could generate one picture for each second [20:33:47 CEST] <furq> you probably just want to convert that to an srt and use the subtitles filter [20:34:23 CEST] <styler2go> I wa sjust looking into the .srt option but i thought the image idea is faster [20:34:44 CEST] <furq> i doubt it [20:42:09 CEST] <rigid> ahoy [20:42:51 CEST] <rigid> i'm trying to compile 3.3.2 with vidstab support, but I _think_ the pkg-config autoconf macro is somehow fubar [20:43:09 CEST] <rigid> config.log https://gist.github.com/4fc604c76f9393c1d866e4c3e1d07c0b [20:43:45 CEST] <rigid> when I run pkg-config manually, it works fine. Plus the log doesn't show quotes around the pkg-config argument. Could that be an issue? [20:54:24 CEST] <styler2go> furq: I am trying with subtitle now, the command i am using is: ffmpeg -f lavfi -i color=color=green:s=1920x1080:r=60 -c:v h264_nvenc -vf subtitles=out.srt eow.mp4 How does ffmpeg know when to stop? do i need to tell it or is the end of subtitle file enough? [20:55:05 CEST] <rigid> nvm, i just found out it's a lib32 <-> lib64 issue [20:55:12 CEST] <rigid> o/ [21:01:51 CEST] <styler2go> It doesn't show any subtitle [00:00:00 CEST] --- Sun Jun 18 2017

1 0

ffmpeg-devel.log.20170616
by burek 17 Jun '17

17 Jun '17

[00:24:05 CEST] <cone-959> ffmpeg 03Michael Niedermayer 07master:611b35627488: avcodec/dnxhd_parser: Do not return invalid value from dnxhd_find_frame_end() on error [00:24:06 CEST] <cone-959> ffmpeg 03Michael Niedermayer 07master:e3fadc57c5c1: avcodec/jpeg2000: Fixes integer overflow in ff_jpeg2000_ceildivpow2() [00:24:07 CEST] <cone-959> ffmpeg 03Michael Niedermayer 07master:3c716682a8b6: avcodec/truemotion2: Move skip computation after checks [01:13:17 CEST] <Zeranoe> Has there been any work done on a non-local means algorithm that uses the GPU? [01:18:04 CEST] <Zeranoe> This http://www.joig.org/uploadfile/2015/0911/20150911035858832.pdf claims a 25x increase in speed [02:25:32 CEST] <atomnuker> considering vulkan is required to and by default doesn't need anything to present to and can just run whatever you want on whatever they sky's the limit [02:32:50 CEST] <cone-959> ffmpeg 03Michael Niedermayer 07master:c0607d88ee1f: avcodec/parser: assert that there is a past buffer if theres a reference into the past [02:44:28 CEST] <Zeranoe> Has anything based on Vulkan been merged? [03:06:37 CEST] <atomnuker> nope [03:37:12 CEST] <TD-Linux> darktable has a noise reduction nlmeans filter implemented with opencl [04:22:03 CEST] <cone-959> ffmpeg 03James Almer 07master:b3446862bfdb: x86/vorbisdsp: optimize ff_vorbis_inverse_coupling_sse [04:51:19 CEST] <cone-959> ffmpeg 03James Almer 07master:623d217ed1ba: avcodec/aacps: move checks for valid length outside the stereo_interpolate dsp function [04:54:56 CEST] <FishPencil> Do most FFmpeg devs hold CS degrees and work in the field? Is FFmpeg a fulltime job for anyone? [11:08:28 CEST] <kierank> FishPencil: everything from no degree to phd i think [11:08:33 CEST] <kierank> i.e doesn't matter [13:42:38 CEST] <kierank> michaelni: did you have a broken build perhaps [13:50:23 CEST] <BBB> did he test the earlier patch which failed to allocate stack space? [13:54:19 CEST] <J_Darnley> He was replying to the right one [13:55:45 CEST] <atomnuker> BBB: btw managed to compile git master on the board, same, no difference in speed since a month [13:56:04 CEST] <atomnuker> all the top 10 functions in perf were from the loopfilter [13:56:25 CEST] <atomnuker> (couldn't even see anything dct related on the first page) [13:56:40 CEST] <BBB> hm... [13:56:50 CEST] <BBB> J_Darnley: lets ask him :) [13:56:56 CEST] <atomnuker> ubitux: why did I manage to compile ffmpeg without gas-preprocessor.pl anywhere on the system? [13:57:14 CEST] <nevcairiel> wasnt that fixed [13:57:28 CEST] <atomnuker> the code in configure even still says it'll reject aarch64 builds without gas-preprocessor [13:58:24 CEST] <atomnuker> yet it still compiled with neon, and I made very sure I'm not tripping and deleted the only gas-preprocessor.pl I had anywhere [13:59:38 CEST] <michaelni> J_Darnley, ill retest but i remeber revertig the od patch and applying the new so it should have been the right one [14:01:37 CEST] <BBB> atomnuker: is the loopfilter in C or in assembly? [14:01:46 CEST] <BBB> (for aarch64) [14:01:47 CEST] <atomnuker> C [14:01:51 CEST] <BBB> wut? [14:01:56 CEST] <BBB> wbs: whathappened?!? [14:02:04 CEST] <BBB> did that get overlooked? [14:02:10 CEST] <J_Darnley> michaelni: Thank you and sorry to be a pain in the backside [14:02:34 CEST] <BBB> aarch64/vp9lpf_neon.o ? [14:02:35 CEST] <ubitux> atomnuker: aarch64 doesn't require gas pp anymore afaik [14:02:39 CEST] <BBB> that doesnt sound right [14:02:59 CEST] <ubitux> atomnuker: actually, even arm should be fine, that might be just for the apple stack [14:03:30 CEST] <ubitux> and even the apple stack should be fine without gaspp for aarch64 [14:03:35 CEST] <atomnuker> ubitux: since which commit? [14:03:49 CEST] <ubitux> since the apple stack works fine? [14:03:58 CEST] <mateo`> https://github.com/FFmpeg/FFmpeg/commit/8aa60606fb64b8280627935b0df55d4d2ae… [14:04:00 CEST] <atomnuker> no, aarch64 doesn't require gaspp [14:04:12 CEST] <ubitux> it may need it before the linked hash [14:04:21 CEST] <ubitux> but on apple only [14:04:28 CEST] <BBB> atomnuker: and vp9dsp_loopfilter_init_aarch64 [14:04:44 CEST] <BBB> atomnuker: there should be loopfilter simd for aarch64 [14:04:46 CEST] <BBB> the source is there [14:04:58 CEST] <atomnuker> BBB: oh, 6.19% ffmpeg_g [.] ff_vp9_loop_filter_h_16_16_neon [14:05:04 CEST] <BBB> \o/ [14:05:20 CEST] <BBB> wbs: nevermind :-p [14:05:33 CEST] <ubitux> btw, after a few days we managed with mateo` to get a mainline linux on the hikey [14:05:38 CEST] <ubitux> unfortunately, still no pmu [14:05:42 CEST] <mateo`> yet [14:05:45 CEST] <ubitux> yet. [14:05:48 CEST] <atomnuker> hikey? [14:06:12 CEST] <ubitux> one of the first aarch64 dev board [14:06:26 CEST] <ubitux> http://www.96boards.org/product/hikey/ [14:06:41 CEST] <ubitux> it's a nightmare but we were able to flash arch on the emmc [14:08:02 CEST] <mateo`> wbs: do you want to fix the vp9 aarch64 asm with apple clang or should i do it ? [14:13:59 CEST] <atomnuker> BBB: https://0x0.st/lKO.txt <- perf printout if you're interested [14:14:17 CEST] <BBB> oh yeah so the top is simply MC [14:14:20 CEST] <BBB> thats totally normal [14:14:31 CEST] <BBB> thats a heavy loopfilter indeed [14:14:57 CEST] <atomnuker> what's up with that memcpy? [14:16:27 CEST] <atomnuker> (maybe its in lavf actually) [14:18:14 CEST] <BBB> would need to see call trees [14:18:17 CEST] <BBB> difficult to say [14:18:33 CEST] <BBB> I dont think theres a ton of memcpy in the decoder [14:18:38 CEST] <BBB> but maybe Im wrong [14:18:47 CEST] <BBB> I guess loopfilter backup is memcpy [14:29:59 CEST] <kierank> J_Darnley: michaelni is encoding the file [14:30:03 CEST] <kierank> whereas you are playing it [14:30:04 CEST] <kierank> afaik [14:30:47 CEST] <J_Darnley> I've tried his exact command now I have the same file. [14:30:55 CEST] <J_Darnley> I get no difference. [14:31:04 CEST] <J_Darnley> No more errors [14:31:17 CEST] <J_Darnley> (See my last email) [14:31:19 CEST] <kierank> then i dunno [14:32:41 CEST] <michaelni> J_Darnley, the error occur in the ffplay command not the encode command [14:32:47 CEST] <michaelni> errorS [14:33:07 CEST] <michaelni> theres in fact noting resemling the original displayed [14:34:48 CEST] <michaelni> J_Darnley, see ML btw ive repled 5min ago in case you didnt see it [14:35:00 CEST] <J_Darnley> I did not, thanks [14:35:16 CEST] Action: J_Darnley moves his mIRC window over [14:41:15 CEST] <gnafu> Wow, mIRC... [14:41:25 CEST] <gnafu> "Now there's a name I've not heard in a long time." [14:42:36 CEST] <J_Darnley> :) [14:43:20 CEST] <J_Darnley> michaelni: is the permutation in the else block "no permutation"? [14:44:25 CEST] <J_Darnley> Looks like all the array indicies are the same [14:47:02 CEST] <michaelni> its probably no perm yes [14:47:45 CEST] <J_Darnley> Okay. I guess I'll look at addressing that. [15:44:11 CEST] <jkqxz> LongChair: wm4: A quick-and-dirty attempt at DRM hwcontext <http://sprunge.us/EYRV>. [15:45:14 CEST] <jkqxz> E.g. on Intel: "./ffmpeg_g -y -init_hw_device drm:/dev/dri/card0 -i in.mp4 -an -filter_hw_device drm0 -vf 'format=nv12,hwupload,format=drm,hwmap=derive_device=vaapi,format=vaapi' -c:v h264_vaapi out.mp4" [15:49:04 CEST] <jkqxz> Unclear how that would need to change for anything else. The Intel VAAPI driver wants a single object containing both planes of NV12, which is what I've hacked up there. [15:51:11 CEST] <jkqxz> I think we might want more metadata about the size of each object. Maybe the descriptor would be better as a list of objects with sizes and then a list of planes as object index + offset and pitch? [15:52:45 CEST] <wm4> what's a dumb buffer? [15:55:31 CEST] <jkqxz> The simplest buffer type the driver is able to use for scanout. (Since the DRM drivers come from rendering for output that's the baseline support for every driver.) [15:55:53 CEST] <wm4> also I think we might need better code structure for MxN device mappings [15:56:15 CEST] <wm4> currently it seems if we support A->B mapping, we put for code for it into A.c, with #ifdef CONFIG_B [15:56:36 CEST] <wm4> maybe we should have map_a_b.c or something [15:56:59 CEST] <wm4> jkqxz: what would other types be? tiled and such? [15:57:02 CEST] <jkqxz> Not necessarily - see OpenCL. I put the code in the "downstream" API if that is well-defined. [15:57:22 CEST] <jkqxz> In this case VAAPI is downstream from DRM, so it's there as map_to. [15:57:47 CEST] <jkqxz> Though yeah, it will get a bit clumsy if there are more variations. [15:59:15 CEST] <LongChair> @jkqxz : checking [15:59:48 CEST] <jkqxz> Tiled is a modifier to other buffers, not a type itself. GEM is the main other type, there are probably more possibilities. [16:01:15 CEST] <jkqxz> (Many of the drivers have 9001 private ioctls implementing all sorts of crazy things.) [16:01:51 CEST] <wm4> apropos ioctl, doesn't libdrm have wrappers for the standard ones? [16:01:53 CEST] <wm4> (not sure) [16:03:49 CEST] <jkqxz> Only some of them. The libdrm API is very fragmented, and much of it is driver-specific. [16:04:39 CEST] <LongChair> i dont think DRM_IOCTL_MODE_CREATE_DUMB has any but DRM_IOCTL_PRIME_HANDLE_TO_FD has some [16:04:40 CEST] <jkqxz> The dumb buffers don't. Looks like the fd <-> handle ones do, though - I can change that. [16:04:47 CEST] <jkqxz> Yeah, that :) [16:05:27 CEST] <wm4> (then why does libdrm even exist) [16:05:35 CEST] <wm4> time to call all linux kernel developers stupid [16:05:49 CEST] <LongChair> DRM_IOCTL_PRIME_HANDLE_TO_FD -> drmPrimeFDToHandle [16:06:03 CEST] <LongChair> or the other way round :) [16:08:24 CEST] <LongChair> jkqxz: if i understand correctly, that attempt creates a dumb buffer pool. in RK case, MPP will create it's own dumb buffers [16:08:39 CEST] <jkqxz> It doesn't need to create anything. [16:08:57 CEST] <jkqxz> You can supply a pool if you want, or just attach a frames context and never allocate in it. [16:10:42 CEST] <jkqxz> What you want for MPP here is to start with a device context (fd can be unset or your DRM node if you have one, doesn't really matter), then whenever the format changes you make a new empty frames context with the appropriate height/width/format and attach that to all of the output frames. [16:11:30 CEST] <J_Darnley> michaelni, BBB: I've sent two patches to address the transpose issue [16:11:57 CEST] <wm4> LongChair: again this doesn't change functionality, it's mostly an "API formalities" thing, so we can handle HW decoding in an uniform way [16:12:48 CEST] <BBB> J_Darnley: cool [16:21:10 CEST] <LongChair> jkqxz: i need ot read that carefully, but is the AV_PIX_FMT_DRM supposed to replace the AV_PIX_FMT_DRMPRIME format i had in the mpp hwdec ? [16:24:58 CEST] <jkqxz> It's the same thing, yeah. Don't really mind on the name of the pixfmt - it seemed wrong to use it the hwcontext name (PRIME is just the sharing mechanism) so I made it DRM throughout, maybe DRM_PRIME would be clearer for the pixfmt type though. [16:25:30 CEST] <LongChair> yeah AV_PIX_FMT_DRM is fine by me, just wanted to make sure :) [16:26:11 CEST] <cone-613> ffmpeg 03Rostislav Pehlivanov 07master:18f09524f72c: configure: use -x instead of -wN ..@ to strip assembly files [16:26:36 CEST] <atomnuker> J_Darnley: had forgotten about this, pushed [16:26:38 CEST] <J_Darnley> I forgot about that ^ [16:26:41 CEST] <J_Darnley> .. too [16:26:54 CEST] <jkqxz> Hmm, maybe DRM_PRIME would be better to make clear that it's always an fd rather than an internal handle or a flinked name. [16:28:15 CEST] <jkqxz> (And if someone cares you could have DRM_FLINK as well, I guess. Does anything new use flink nowadays?) [16:31:28 CEST] <LongChair> jkqxz: so what's your plan, finsih up with VAAPI & me adapting MPP to it ? [16:33:49 CEST] <jkqxz> Dunno. I wrote that to try to clarify what the requirements should be, so that the external API part can be set. [16:35:08 CEST] <jkqxz> VAAPI doesn't really need it, though it makes a nice test case to see it working. [16:38:25 CEST] <LongChair> jkqxz: up to you :) [17:24:23 CEST] <jkqxz> LongChair: wm4: New version <http://sprunge.us/fVaM>. DRM -> DRM_PRIME for the pixfmt, and I've made the descriptor a bit more verbose and hopefully clearer. [17:24:49 CEST] <jkqxz> Also the DRM format is per-object. [17:28:51 CEST] <wm4> jkqxz: how would rockchip's funny 10 bit format fit in there? [17:29:32 CEST] <wm4> also why is the format per object? [17:29:33 CEST] <jkqxz> Just make a new pixfmt for it to use as sw_format, and the DRM stuff is whatever they use. [17:29:37 CEST] <wm4> I'm not sure how much that makes sense [17:29:47 CEST] <wm4> I know vaapi uses different formats per plane [17:29:55 CEST] <wm4> but the rockchip thing uses a format for the whole thing [17:30:18 CEST] <jkqxz> The rockchip thing is also one object, though? [17:30:26 CEST] <wm4> (rockchip also forces RGB conversion when you use these frames, so it "sort of" makes sense) [17:30:28 CEST] <wm4> hm, not sure [17:30:33 CEST] <wm4> LongChair: ? [17:31:13 CEST] <jkqxz> I'm more thinking of Mesa, where you get an R8 object and an RG88 object separately. [17:31:38 CEST] <jkqxz> So that really would be two separate objects and want this style. [17:32:22 CEST] <BBB> J_Darnley: can we use the permutation table directly in the quantization stage? [17:32:35 CEST] <BBB> J_Darnley: it seems strange that wed need a specific extra place to check for perm_type [17:32:42 CEST] <wm4> jkqxz: yeah, ok, I get it [17:32:42 CEST] <BBB> not that Im against it, and maybe this is more a question for michaelni [17:33:00 CEST] <wm4> jkqxz: the thing is, NV12 actually still has 2 planes [17:33:19 CEST] <wm4> each plane has an offset into the buffer, and a stride [17:33:34 CEST] <wm4> but I suppose that's why you have separate arrays [17:33:52 CEST] <wm4> so it's up to the final API user to know about the difference [17:33:53 CEST] <jkqxz> Maybe there should be an AV_PIX_FMT_WTF to represent something opaque and bizarre which you shouldn't look inside, and we can use that as the sw_format for rockchip 10-bit and similar things. [17:34:07 CEST] <jkqxz> In the absence of swscale support that's basically what it is, since you can't do anything else with it. [17:34:21 CEST] <wm4> would it be possible to define an opaque sw_format? or the thing that I wanted from the beginning: a hw-API-specific int64 identifier [17:34:33 CEST] <wm4> AVHWFramesContext.sw_format_native or something [17:36:40 CEST] <jkqxz> I think the answer to the format problem depends on how the multiple-plane ones are actually represented internally. [17:36:59 CEST] <jkqxz> Maybe it's just meaningless on the object, and should instead be attached to the plane - that would match how EGL uses it? [17:37:32 CEST] <jkqxz> Or does EGL import on rockchip actually have a single NV12 "plane" in DRM_FORMAT_NV12? [17:37:50 CEST] <jkqxz> Which magically does ... something ... in the driver. [17:39:15 CEST] <jkqxz> (The dumb buffers in that patch are entirely independent of the format - I just gave it a size and made up the format myself.) [17:40:47 CEST] <wm4> well LongChair linked the (working) EGL code for this [17:40:52 CEST] <wm4> but I think the answer is yes? [17:41:04 CEST] <wm4> they don't allow you to actually sample from the planes [17:41:09 CEST] <wm4> you get a virtual RGB texture [17:42:36 CEST] <J_Darnley> BBB: I don't know. Where could I find that table or related code? [17:42:53 CEST] <BBB> I dont know, I would probably defer that question to michaelni [17:43:53 CEST] <BBB> I would guess its idct_permutation[]? [17:44:03 CEST] <BBB> but maybe theres something special to the one used in quantization [17:44:36 CEST] <BBB> or maybe it needs the inverse (like T-1; that should be trivial to write but maybe there was a reason michaelni didnt want to add it in the struct, e.g. to reduce memory usage or so) [17:44:46 CEST] <BBB> or maybe a hand-unrolled quant is faster? [17:44:50 CEST] <BBB> not sure [17:45:25 CEST] <michaelni> its hand unrolled for speed [17:48:04 CEST] <BBB> that makes sense [17:48:49 CEST] <BBB> michaelni: do you think a default: based on T-1 idct_permutation makes sense? or would you prefer it to assert out so we write the correct code in that place? [17:49:04 CEST] <BBB> (default only if the hand-unrolled version for that perm_type is missing, obviously) [17:49:55 CEST] <BBB> (I have no preference, Im just blurping out random ideas, Im fine with things as they are) [17:51:19 CEST] <michaelni> i like the assert as it makes sure theres always optimal code and nothing missing [17:52:20 CEST] <BBB> ok [17:52:49 CEST] <BBB> J_Darnley: if you need help debugging the mismatches from michaelni, let me know [17:53:08 CEST] <BBB> I think were slowly getting closer to perfect, even if were not exactly there yet [17:53:14 CEST] <J_Darnley> I will. I'm just getting the file as we speak [17:53:36 CEST] <BBB> you will look at it? or you will need help? :-p [17:53:50 CEST] <BBB> kierank: Im sorry for the rabbit hole [17:55:18 CEST] <J_Darnley> I will in a short while [18:27:32 CEST] <jkqxz> wm4: Having looked at that a bit more, I think the set of "planes" should just be the set of things you import to EGL. Anything else will just cause confusion. [18:27:55 CEST] <jkqxz> So, the DRM format goes with the "plane", and they probably shouldn't be called planes. [18:30:56 CEST] Action: J_Darnley gets back to work [18:39:31 CEST] <wm4> jkqxz: depends how you use it with native DRM I guess, but maybe that's not much different [18:45:04 CEST] <J_Darnley> I can reproduce michaelni's differences. [18:46:17 CEST] <J_Darnley> BBB: did you expect the new functions to produce the same output as C or MMX? [18:46:25 CEST] <BBB> both? [18:46:28 CEST] <J_Darnley> I've forgotten which we were aiming for. [18:46:42 CEST] <BBB> mmx, basically, but Im not sure they ever are differeny [18:47:20 CEST] <BBB> I believe the idct itself should always be identical, but some things may not honor perm_type and then it would behave different from C [18:47:28 CEST] <BBB> (but then mmx/c would differ also) [18:54:13 CEST] Action: J_Darnley wonders whether that transpose issue was also the problem with fate [18:59:58 CEST] <J_Darnley> no, not entirely [19:01:18 CEST] <BBB> you mean the wmv1 failure? [19:01:26 CEST] <BBB> (vsynth) [19:01:27 CEST] <J_Darnley> yes [19:01:47 CEST] <BBB> it would probably be part of it [19:01:57 CEST] <J_Darnley> mmm part [19:02:01 CEST] <BBB> but michaelni may be able to indicate other parts where similar code needs to be added [19:02:24 CEST] <BBB> Im more concerned about cases where perm_type is entirely ignored, especially in semi-custom encoders like wmv2 [19:03:42 CEST] <J_Darnley> In his test I do get a different result between the mmx and the new sse2. However I get the same result if I use C and the new sse2 [19:04:08 CEST] <BBB> so mmx/c are different? [19:04:23 CEST] <BBB> all hacks are modeled after the C code btw [19:04:29 CEST] <BBB> I still dont fully understand the mmx code [19:04:40 CEST] <J_Darnley> I think they always were because the mmx is not used for -idct simple [19:05:07 CEST] <BBB> I thought that had to do with perm_type being ignored by some code [19:05:17 CEST] <BBB> and mmx perm_type is different than c perm_type [19:05:30 CEST] <BBB> but maybe results are actually different for the 2 [19:05:36 CEST] <BBB> if they are, thatd be interesting [19:05:45 CEST] <BBB> and maybe we need to model simple, not simple_mmx [19:05:46 CEST] <BBB> ?? [19:14:38 CEST] <J_Darnley> Here's some good news: the fate failues with the sse2 are down to just wmv and "mdec" [19:14:48 CEST] <BBB> wmv1? [19:14:54 CEST] <J_Darnley> yes [19:14:58 CEST] <BBB> mdec [19:14:59 CEST] <BBB> hm [19:15:14 CEST] <BBB> of all the things I am not interested in, wmv1 must be pretty much on top of that list [19:15:16 CEST] <J_Darnley> fate-vsynth{1,2,3_lena}-wmv1 [19:15:23 CEST] <BBB> but I can imagine that mdec is high on that list also [19:15:25 CEST] <BBB> :-p [19:15:30 CEST] <BBB> lets have a look [19:15:31 CEST] <J_Darnley> fate-mdec fate mdec-v3 [19:15:47 CEST] <BBB> mdec is decoding? [19:16:05 CEST] <J_Darnley> I don't know, I haven't looked at what the tests do yet. [19:16:34 CEST] <J_Darnley> I would say "probably, it sounds like some obscure format nobody wants to create" [19:19:28 CEST] <BBB> its based on idct_put and appears to use the scantable correctly [19:19:32 CEST] <BBB> it does have a weird line: [19:19:49 CEST] <BBB> if (avctx->idct_algo == FF_IDCT_AUTO) [19:19:49 CEST] <BBB> avctx->idct_algo = FF_IDCT_SIMPLE; [19:20:41 CEST] <J_Darnley> Skipping the "incorrect" mmx , maybe [19:21:01 CEST] <BBB> its after init, not before [19:21:29 CEST] <J_Darnley> After initing the idct dsp struct? Then I'm not sure [19:22:09 CEST] <BBB> yes, and the scan table [19:22:54 CEST] <BBB> maybe its insignificant [19:22:57 CEST] <BBB> not sure [19:23:07 CEST] <BBB> I can look at mdec, it may provide some insights [19:23:11 CEST] <BBB> latest branch name? :) [19:23:16 CEST] <BBB> Ill check after lunch [19:23:26 CEST] <J_Darnley> let me push then it should be mpeg2_asm6 [19:23:43 CEST] <BBB> okay [19:24:03 CEST] <J_Darnley> done [19:25:50 CEST] <BBB> while its building, Ill head out for lunch [19:25:51 CEST] <BBB> brb [19:25:58 CEST] <J_Darnley> have a nice lunch [19:29:06 CEST] <tdjones> atomnuker: Could you help me debug psy in vorbis when you have a chance? It is failing to return any window suggestions for the second channel of audio even when I duplicate two mono channels for the input. [19:30:25 CEST] <tdjones> Here's the commit I'm working off of [19:30:36 CEST] Action: tdjones posted a file: 0001-WIP-libavcodec-vorbisenc-Include-AAC-psy-model.patch (10KB) <https://matrix.org/_matrix/media/v1/download/matrix.org/UttmUwbsBuNQrUyVEYm…> [19:35:55 CEST] <J_Darnley> BBB: look at e3e3c82555 and tell me if you think that was a good idea? :D [19:39:34 CEST] <atomnuker> tdjones: what does it return? [19:40:22 CEST] <tdjones> It just returns ONLY_LONG for the second channel [19:41:19 CEST] <tdjones> It behaves how you would expect in aac, so it must be something that I've done incorrectly [19:42:44 CEST] <atomnuker> tdjones: what happens if you zero out the left and then the right channel? [19:43:15 CEST] <atomnuker> and you look only at the first channel's window type [19:50:31 CEST] <tdjones> Muting the left channel ends up returning only_long for both channels [19:50:43 CEST] <tdjones> Muting right channel returns only_long for first channel again [19:53:33 CEST] <J_Darnley> Maybe I should be so hard on the guy, the code didn't have the same idctdspback then. [19:56:34 CEST] <atomnuker> tdjones: so if you mut the right channel you get something other than only_long on the second channel? [19:56:37 CEST] <atomnuker> *mute [19:57:03 CEST] <tdjones> I said that backwards, my bad [19:57:12 CEST] <tdjones> It returns only_long for second channel [19:57:59 CEST] <tdjones> What I meant is that muting the right channel seems to have no effect on the output of the psy model [20:01:12 CEST] <atomnuker> well, drop the patch for now, the transient detector will be easily replaced by the opus one (which needs a little more work) [20:01:47 CEST] <atomnuker> its more important to get more functionality out of the encoder [20:02:30 CEST] <atomnuker> if you need to test whether switching between transient and non-transient frames work just add a counter and e.g. mark every 10th frame as a transient [20:02:54 CEST] <tdjones> I have block switching and window application working correctly, but I feel that is pointless now without any psy model to provide the input [20:03:02 CEST] <atomnuker> (and make sure to be able to handle cases where either the entire file has no transients or every single frame is a transient) [20:03:58 CEST] <atomnuker> tdjones: I'll try to push the opus psy with just transient handling out by the end of the weekend [20:05:26 CEST] <atomnuker> until then see if you can get a classbook search for the residual working [20:06:00 CEST] <tdjones> atomnuker: Alright, I appreciate the help. Thank you [20:09:51 CEST] <atomnuker> tdjones: though if you think its more useful to have some sort of temporary transient handling first go for it and try debugging what goes wrong [20:10:21 CEST] <atomnuker> just put printfs in both the aac and the vorbis encoder and look for what's different on the psy system inputs [20:11:07 CEST] <tdjones> atomnuker: That's what I've been doing, I'll probably try some more and put it on the sidelines for a bit if I don't make progress [20:11:29 CEST] <atomnuker> alright [20:20:57 CEST] <BBB> J_Darnley: dunno& it seems to me we should set the idct_type before (not after) the idctdsp init? [20:22:54 CEST] <J_Darnley> That would be the proper thing to do but doesn't help us identify where it fails when we do use permutation. [20:23:48 CEST] <J_Darnley> Do you know if it is right to call ff_init_scantable with ff_zigzag_direct and not something out of a DSP struct? [20:39:09 CEST] Action: J_Darnley does to look at wmv1 [20:55:18 CEST] <J_Darnley> Ah. It is in mpegvideo_enc [20:56:34 CEST] <BBB> I think its ok, but Im not 100% sure [20:56:38 CEST] <J_Darnley> ah but might really be h263 [20:59:26 CEST] <J_Darnley> but there's no idct in there [20:59:28 CEST] <BBB> Im not 100% sure about the mdec one, it looks very trivial [20:59:37 CEST] <BBB> Ill have to actually debug tht in detail :/ [21:00:11 CEST] <J_Darnley> fun! [21:01:52 CEST] <BBB> so much fun [21:02:11 CEST] <BBB> now imagine you having to explain this to an audience of people in a blog or at vdd of people that are not familiar with mpegvideo [21:02:29 CEST] <BBB> and you cant tell them to go read it because torture is forbidden by the geneva convention [21:06:43 CEST] <nevcairiel> that only covers prisoners, not willing participants [21:07:42 CEST] <BBB> oh I see [21:08:00 CEST] <BBB> is locking them up in a room with jdarnley and throwing away the key prisoner, or willing? [21:08:05 CEST] <BBB> (they entered voluntarily) [21:09:57 CEST] <BBB> J_Darnley: fate-mdec passes for me [21:10:00 CEST] <BBB> J_Darnley: what fails? [21:13:20 CEST] <BBB> or should I test without the -idct simple flag? [21:15:46 CEST] <J_Darnley> Yes, you need to force it to use the new code. I suggest adding to selection in avcodec/x86/idctdsp_init.c [21:18:03 CEST] <J_Darnley> add "|| avctx->idct_algo == FF_IDCT_SIMPLE" to line 103 [21:47:47 CEST] <BBB> oh [21:47:53 CEST] <BBB> J_Darnley: yeah theres definitely a bug [21:48:01 CEST] <BBB> I dont know if its in the C or in the SSE2 [21:48:46 CEST] <atomnuker> what the hell is subps doing, it should only do a subtraction [21:49:00 CEST] <iive> ? [21:49:15 CEST] <atomnuker> yet I get y[0], y[1], y[3], y[2] instead of y0123 [21:49:45 CEST] <atomnuker> every pair of numbers is the other way around [21:49:51 CEST] <nevcairiel> that doesnt sound like something subps would do [21:49:56 CEST] <atomnuker> (-10.771465 72.416946 -4.435959 22.024652) vs (72.416946 -10.771465 22.024652 -4.435959) [21:50:37 CEST] <atomnuker> I checked and all the inputs are exactly the way they should be, no swapping or anything [21:50:51 CEST] <atomnuker> yet as soon as I subtract them I get this [21:51:12 CEST] <iive> can we see the whole code? [21:51:23 CEST] <iive> i've used subps, no suprises there [21:52:24 CEST] <iive> and the above is more y1032 vs y0123 [21:53:24 CEST] <atomnuker> https://0x0.st/lNc.asm [21:53:36 CEST] <iive> you know that in register values are y[3] [2] [1] [0] compared to memory locations. [21:53:40 CEST] <BBB> something is clearly wrong in mdec here [21:53:53 CEST] <BBB> I dont think the ac quantizers are initialized correctly [21:55:00 CEST] <atomnuker> iive: m2 is completely the right way around and everything matches [21:58:37 CEST] <atomnuker> iive: nevermind, my reference C code had them swapped [21:59:05 CEST] <iive> yeh, i was checking the swap code :D [21:59:46 CEST] <J_Darnley> BBB: so there might be a bug before the idct is even run [22:00:25 CEST] <BBB> well the idct is still returning wrong results [22:00:27 CEST] <BBB> Im testing... [22:09:43 CEST] <cone-822> ffmpeg 03Michael Niedermayer 07master:e77ddd31a8e1: avcodec/shorten: Sanity check maxnlpc [22:09:43 CEST] <cone-822> ffmpeg 03Michael Niedermayer 07master:16d6cc2168b6: avcodec/wavpack: Change wp_log2() to unsigned [22:09:43 CEST] <cone-822> ffmpeg 03Michael Niedermayer 07master:dfb61ea26300: avcodec/jpeg2000dec: Check nonzerobits more completely [22:22:34 CEST] <BBB> huh [22:22:36 CEST] <BBB> J_Darnley: [22:22:37 CEST] <BBB> pand m3, m5 [22:22:38 CEST] <BBB> por m3, m6 [22:22:38 CEST] <BBB> why? [22:24:16 CEST] <J_Darnley> huh? That's merging in the stored DC only part [22:25:44 CEST] <BBB> but m3 has nothing in it [22:25:49 CEST] <BBB> m3 is a temporary in the 8x8 transpose [22:26:41 CEST] <J_Darnley> oh I guess I was overzealous with my typing [23:18:30 CEST] <BBB> J_Darnley: https://pastebin.com/mVvA8fAR [23:18:36 CEST] <BBB> J_Darnley: thats the output from the failing mdec block [23:18:54 CEST] <BBB> it looks like it may still be related to the rounding in the dc-only case [23:22:53 CEST] <BBB> J_Darnley: and https://pastebin.com/J1CiCSfA with 1d output from the C [23:23:01 CEST] <BBB> havent gotten much further yet... [23:23:41 CEST] <BBB> hm actually that may be wrong, ignore for now [23:27:13 CEST] <BBB> and now it matches :-/ [23:43:19 CEST] <BBB> I dont know whats wrong yet. when I call the C function (which gives the correct output) and manually call the avx idct on the transposed block data, all block output matches (I think) [23:43:30 CEST] <BBB> but when I remove -idct simple, data doesnt match [23:43:39 CEST] <BBB> maybe the transpose in permutation isnt working correctly [23:43:41 CEST] <BBB> not sure yet [23:45:12 CEST] <BBB> I think the quant_table is not transposed [23:45:46 CEST] Action: J_Darnley reads [23:48:04 CEST] <BBB> ah yes thats it [23:48:11 CEST] <BBB> quant_matrix needs to be transposed in mdec.c [23:48:22 CEST] <BBB> if I do that manually, the fate test passes [23:48:31 CEST] <BBB> lemme see how mpegvideo does that, we can probably just copy that [23:49:01 CEST] <J_Darnley> mmhm... we need to transpose on demand [23:51:16 CEST] <BBB> michaelni: why is ff_mpeg1_default_intra_matrix[] 256 if it only has 64 entries (in mpeg12data.c)? [23:51:41 CEST] <kierank> BBB: https://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/2012-November/057056.html [23:52:07 CEST] <BBB> da fuq [23:52:13 CEST] <J_Darnley> That was quick [23:52:14 CEST] <kierank> my thoughts too [23:53:59 CEST] <BBB> hum [23:53:59 CEST] <BBB> ok [23:54:00 CEST] <BBB> so [23:54:05 CEST] <BBB> after that, the sse2 function passes [23:54:07 CEST] <BBB> however........ [23:54:10 CEST] <BBB> the mmx one still fails [23:54:16 CEST] <BBB> I do not at all understand why [23:54:46 CEST] <J_Darnley> will it use the correct permutation for mmx? [23:54:57 CEST] <BBB> it should [23:55:01 CEST] <BBB> Im basically un-permutating it [23:55:10 CEST] <BBB> that should work for all permutations [23:55:22 CEST] <BBB> J_Darnley: https://pastebin.com/gzs0DB54 [23:55:26 CEST] <BBB> that fixes mdec for me [23:55:38 CEST] <BBB> what was the other? you said it was wmv1 encoding, right? or was it wmv1 decoding? [23:55:50 CEST] <J_Darnley> encoding [23:55:53 CEST] <BBB> (I considered that the quant fix you made in mpegvideoenc may have fixed wmv1 encoding) [23:55:59 CEST] <J_Darnley> (maybe decoding too) [23:56:05 CEST] <BBB> oh its still encoding, even after the quant fix? [23:56:16 CEST] <BBB> (the quantization getting support for transpose permutation) [23:56:28 CEST] <J_Darnley> yeah, I know what you mean [23:56:30 CEST] <J_Darnley> anyway [23:56:35 CEST] <BBB> but still broken after that? [23:56:51 CEST] <J_Darnley> yes, the output is not identical between c and sse2 [23:57:00 CEST] <BBB> okiedokie [23:57:37 CEST] <J_Darnley> That one is a little harder to trace [23:58:13 CEST] <BBB> nope, encoding is identical for me [23:58:27 CEST] <BBB> oh wait that was decoding [23:58:28 CEST] <BBB> doh [23:58:30 CEST] <BBB> hold on [23:58:35 CEST] <BBB> ffmpeg.exe can be so hard to use [23:59:19 CEST] <BBB> yup, reproduceable [23:59:20 CEST] <BBB> ok [23:59:22 CEST] <BBB> will debug [23:59:28 CEST] <BBB> this is soooooooooo exciting [00:00:00 CEST] --- Sat Jun 17 2017

1 0

ffmpeg.log.20170616
by burek 17 Jun '17

17 Jun '17

[00:03:07 CEST] <FishPencil> I think nlmeans might be "better" [00:08:37 CEST] <FishPencil> Wow nlmeans is slow [00:33:41 CEST] <ac_slater> hey guys. I'm muxing a video stream with a data stream in an mpegts container. Is it odd if my data stream has a PTS that simply starts at 1 and monotonically increases for every packet? [00:34:03 CEST] <ac_slater> or should the data PTS be relatable to the nearest video PTS? ... [00:35:19 CEST] <ac_slater> (I guess PTS and DTS) [01:02:32 CEST] <ac_slater> no one? Damm [01:02:44 CEST] <ac_slater> I've been stuck on this for days. Maybe I should make a mailing list post [01:36:30 CEST] <alexpigment> hey guys, is there a way to get the source code from a zeranoe nightly? [01:37:28 CEST] <alexpigment> ffmpeg-20170601-bd1179e-win32-shared.zip is what i'm looking at [01:37:46 CEST] <alexpigment> i'd like to basically re-build this and leave out unnecessary libraries [01:43:48 CEST] <c_14> git clone https://git.ffmpeg.org/ffmpeg.git; cd ffmpeg; git checkout bd1179e [01:44:05 CEST] <JEEB> if you have unlimited bandwidth raw will just be quicker. but you usually don't have that. [01:44:17 CEST] <JEEB> welp, was way up there [01:46:01 CEST] <alexpigment> c_14 thanks [01:46:58 CEST] <ac_slater> guys, is there something special I have to do to mux video sources with B-frames? ie - h264 ? [01:47:24 CEST] <JEEB> with avformat and proper pts, no [01:47:36 CEST] <JEEB> I mean, in avformat [01:47:57 CEST] <ac_slater> If I just read all packets from a file, for example, then mux them into an mpegts container with av_interleaves_write_frame, I get out of order PTS errors [01:48:29 CEST] <JEEB> I know that some demuxers sometimes give bad timestamps [01:48:45 CEST] <ac_slater> ah right, I guess I'm just reading raw H264 [01:48:47 CEST] <JEEB> for example the MPEG-TS demuxer I've had sometimes give me issues [01:48:58 CEST] <JEEB> ac_slater: read it with avformat? [01:49:03 CEST] <ac_slater> yea [01:49:05 CEST] <JEEB> I would guess that's one of the things that should work :P [01:49:20 CEST] <ac_slater> I'll post a small example + file, seriously like 30 lines of code [01:49:22 CEST] <JEEB> although in that case you get no initial frame rate in most cases [01:50:07 CEST] <JEEB> but yea, sleep for me :P [01:50:11 CEST] <JEEB> almost 3 in hte morning already [01:50:19 CEST] <ac_slater> JEEB: nooooo you're my only hope ;) [01:50:20 CEST] <ac_slater> night bud [02:36:20 CEST] <thebombzen> for the builds for windows, is there any particular reason to pick shared over static or vice versa? it seems to me that shared is smaller in filesize but static could cause fewer issues? what would be the reason to pick one or the other? [03:10:25 CEST] <relaxed> thebombzen: shared would be for third party applications that use ffmpeg's libs, static would be easier if you only want ffmpeg, ffprobe, etc [03:10:32 CEST] <thebombzen> alright thanks [03:41:11 CEST] <hendry> Anyone know if EXT-X-I-FRAME-STREAM-INF is actually needed for HLS streaming? IIUC it's some sort of key frame index, but I've seen videos playback without it, so I am not sure what it's value is. [04:01:09 CEST] <waterworks> I have a problem with an x264/mp4 file having wrong framerate and duration when creating it with the C API. FPS should be 60, but is usually 61.02. I have a minimal example that reproduces it: https://pastebin.com/U3hhqYLR [04:17:37 CEST] <DHE> hendry: from a reading of the spec, it might make trickplay (aka fast-forward) work better but otherwise seems useless [04:18:36 CEST] <hendry> DHE: "trickplay"? didn't know about that term. Thanks =) [04:19:00 CEST] <hendry> waterworks: i would try reproduce in shell with ffmpeg binary to be sure [04:20:47 CEST] <ac_slater> waterworks: good choice using c++14 [04:21:19 CEST] <DHE> need an ffmpeg filter that merges several frames together into a single frame in such a way that it looks like a tape/analog VCR in fast-forward mode. (also reduces framerate, obviously) [04:21:58 CEST] <ac_slater> DHE: have fun writing that [04:22:47 CEST] <DHE> haha... that is so far outside my area of expertise... [04:23:07 CEST] <waterworks> hendry, ac_slater: ffprobe -show_streams reports "codec_time_base=59/7200" and "avg_frame_rate=3600/59" which is the problem, it's ignoring that I'm setting them. [04:23:44 CEST] <waterworks> This is not a problem if my container is avi, however. In that case if I dump every packet with show_packets, pts seems to be unused? [04:24:43 CEST] <ac_slater> waterworks: hmm nothing looks too out of the ordinary [04:24:51 CEST] <waterworks> The correct values for both should be 1/120 and 60/1. [04:25:35 CEST] <ac_slater> what containers/output formats are choosing/overriding your timebases? [04:26:03 CEST] <ac_slater> cause it looks like this example code just encodes h264 then writes it [04:26:10 CEST] <ac_slater> and it's a raw format with no timing [04:26:35 CEST] <waterworks> No, it muxes a stream into an mp4 container. [04:26:52 CEST] <ac_slater> oh right via path [04:26:55 CEST] <ac_slater> gotcha [04:27:15 CEST] <ac_slater> waterworks: you're using ffmpeg 3.3? [04:27:31 CEST] <waterworks> ac_slater: yes, I have the latest of the website [04:28:48 CEST] <ac_slater> waterworks: I would try 3.2 honestly. Lots of mp4 changes [04:29:04 CEST] <ac_slater> Also, you might want to ask ffmpeg-devel or post on the mailing list [04:29:09 CEST] <ac_slater> cause this might be a bug [04:29:13 CEST] <waterworks> ac_slater: I upgraded to 3.3 from 3.2 before this, same problem [04:29:26 CEST] <ac_slater> shit. What if you write to test.ts [04:29:29 CEST] <ac_slater> ie - mpegts [04:32:47 CEST] <waterworks> ac_slater: Only have avi and mp4 containers enabled in this configuration, give me a few min to change linker settings [04:34:58 CEST] <ac_slater> sorry mate. I think it might shed some light on it. But you might not be doing everything that the output context needs in terms of timebase [04:35:07 CEST] <ac_slater> you're setting it on the codec, but not the container [04:35:23 CEST] <ac_slater> I know how mpegts works, so maybe it'll shed some light [04:35:50 CEST] <waterworks> yes mpegts does it right [04:36:55 CEST] <waterworks> the format context has no timing fields [04:38:20 CEST] <ac_slater> hmm [04:38:39 CEST] <waterworks> mkv works as well [04:39:21 CEST] <waterworks> and mov doesn't, so that family then [04:39:32 CEST] <ac_slater> yea it's an mp4 thing [04:39:52 CEST] <ac_slater> I've ran into that container type causing issues with time stamps as well [04:39:55 CEST] <ac_slater> there is something you have to do [04:42:10 CEST] <waterworks> I have no clue what it'd be, I've been staring at it for days [04:45:12 CEST] <ac_slater> waterworks: for AVStream::time_base, the doc says the muxer will overwrite the value [04:45:18 CEST] <ac_slater> when encoding [04:45:22 CEST] <ac_slater> / muxing [04:45:35 CEST] <ac_slater> (which may or may not be related to the user-provided one, depending on the format) [04:45:49 CEST] <waterworks> ac_slater: yes, after write_header it gets correctly changed to 1/15360. The issue is the codec however [04:46:06 CEST] <ac_slater> not the muxer? [04:46:38 CEST] <waterworks> no clue, just what ffprobe tells me [04:46:57 CEST] <waterworks> only in the mp4 family of containers those settings don't get written [04:47:20 CEST] <ac_slater> I think if you ask in #ffmpeg-devel, someone might know specifically about this [04:49:01 CEST] <waterworks> support even allowed there? from the site it seemed like project developer only talk [04:49:24 CEST] <ac_slater> well, you're determining if you're going to file a bug or not [04:50:09 CEST] <waterworks> cannot be a bug, I know OBS Studio can write flawless MP4 files [04:50:26 CEST] <ac_slater> yea and the ffmpeg commandline tool can do it as well [04:50:48 CEST] <ac_slater> you should maybe try to set the log level to trace in your application and stare at it [04:51:49 CEST] <ac_slater> I see some mention to set vsync=2 in your muxer AVDictionary [04:52:25 CEST] <ac_slater> the trace log will show you what defaults the muxer is applying (most times) [04:53:27 CEST] <waterworks> do you want to see it? everything is normal [04:53:44 CEST] <k_sze[work]> Whatever happened to the -level option of ffv1? [04:54:03 CEST] <k_sze[work]> ffmpeg -help encoder=ffv1 doesn't list it. [04:54:39 CEST] <ac_slater> might as well upload the trace log wherever mpeg4 is mentioned [04:55:09 CEST] <waterworks> ac_slater: not mentioned, only libx264 output [04:55:17 CEST] <ac_slater> hmm [04:55:53 CEST] <ac_slater> you did av_log_set_level(AV_LOG_TRACE); ? [04:56:03 CEST] <waterworks> ac_slater: yes [04:57:04 CEST] <ac_slater> what happens if you take your raw h264 file and put it in a mp4 container via `ffmpeg -i raw.h264 -vcodec copy test.mp4` ? [04:57:16 CEST] <ac_slater> might as well add `-v 99` at the end to get a trace log [04:59:18 CEST] <waterworks> well I don't have that [05:01:22 CEST] <ac_slater> :( why [05:02:22 CEST] <ac_slater> you said your app works if you spit out a mpegts or mkv. Just use `ffmpeg -i test.ts -vcodec copy raw.h264` [05:02:49 CEST] <waterworks> Ah, I don't know much about the CLI [05:03:34 CEST] <ac_slater> it's awesome and a good way to test before you write libav* stuff [05:04:30 CEST] <ac_slater> I'm going offline waterworks, good luck man. Please post to the mailing list. They're quick over there [05:04:37 CEST] <waterworks> ac_slater: ffmpeg provided an invalid file [05:04:56 CEST] <ac_slater> waterworks: wait [05:05:23 CEST] <ac_slater> doing the 2 commands I said (strip the GOOD h264 from your muxed file, then REMUX with CLI) &. that STILL failed? [05:05:26 CEST] <waterworks> using your commands, it produced an mp4 file with 51.58 fps [05:05:54 CEST] <ac_slater> try doing `ffmpeg -i raw.h264 -vcodec copy -vsync 2 test.mp4` [05:06:28 CEST] <waterworks> still same and invalid unfortunately [05:06:33 CEST] <ac_slater> awesome [05:06:38 CEST] <waterworks> I get a message from the muxer this time around though [05:07:31 CEST] <waterworks> When using ffmpeg and your commands -> https://pastebin.com/RUw0V4KW [05:08:11 CEST] <ac_slater> right since you're feeding the muxer h264 without timestamps [05:08:42 CEST] <ac_slater> `ffmpeg -i raw.h264 -framerate 60 -vcodec copy -vsync 2 test.mp4` [05:09:04 CEST] <waterworks> still same [05:09:46 CEST] <ac_slater> `ffmpeg -r 60 -i raw.h264 -vcodec copy -vsync 2 test.mp4` [05:10:35 CEST] <waterworks> Better, but this time it's playing slower instead of faster like my code [05:10:44 CEST] <waterworks> 59.78 fps [05:10:51 CEST] <ac_slater> is that intended? [05:10:59 CEST] <waterworks> what do you mean? [05:11:01 CEST] <ac_slater> ie - what's your goal here [05:11:04 CEST] <ac_slater> 60fs? [05:11:06 CEST] <ac_slater> fps * [05:11:06 CEST] <waterworks> yes [05:11:16 CEST] <ac_slater> 59.87 isn't acceptable? [05:11:19 CEST] <waterworks> complete normal video creation, no effects [05:11:21 CEST] <waterworks> and no it is not [05:11:34 CEST] <waterworks> the duration must be 1:1 [05:11:44 CEST] <ac_slater> remove the -vsync option just for kicks [05:12:24 CEST] <waterworks> same output [05:12:56 CEST] <ac_slater> thinking [05:13:32 CEST] <waterworks> "codec_time_base=1713/204800" = 0.00836425781, where does it even get this value? it should be 1/120 [05:14:02 CEST] <waterworks> same with "avg_frame_rate=102400/1713" = 59.7781669586, it just sets it to whatever it seems like, same with my code [05:14:46 CEST] <ac_slater> you can specify avg_frame_rate on the AVFormatContext if I remember correctly [05:14:55 CEST] <waterworks> if I show_streams on a valid OBS Studio file, those are what I see, or if I create an mkv I see the right values as well [05:15:27 CEST] <waterworks> nah ac_slater, only AVStream has the avg_frame_rate field [05:15:41 CEST] <ac_slater> ah right [05:15:48 CEST] <waterworks> I looked in the source code for the MOV muxing family and theres no such dictionary option there either [05:18:24 CEST] <waterworks> it is strange indeed, I'm confident in saying I have not missed setting anything in the code [05:18:52 CEST] <ac_slater> also check `ffmpeg -h muxer=mp4` [05:19:02 CEST] <ac_slater> same information on the website somewhere [05:19:36 CEST] <ac_slater> waterworks: your goal should be to get your raw h264 file muxed into an mp4 container via the command line tool first [05:19:51 CEST] <ac_slater> since you'll have faster iteration time and can replicate it easily [05:20:01 CEST] <ac_slater> (via libavformat/codec) [05:20:08 CEST] <ac_slater> I g2g sorry I wasnt more help [11:09:10 CEST] <Nacht> Quick question. For AAC-LC, libfdk_aac or just regular aac as Codec ? [11:09:10 CEST] <DogTheFrog> Hello everyone, i'd like to push a TS/UDP , TS/RTP , or ES/RTP Stream from an Extron SMP 351 to my server running ffmpeg to redistribute the Stream to other users. Is this possible? It worked with pulling from the Extron (-i rtsp://......) but i don't wanna open a port for the smp, i wanna open the port on the server for ffmpeg and push the stream to ffmpeg. Sorry for my bad english, hope you understand it. How does this work? [11:09:29 CEST] <furq> Nacht: fdk is better, but not that much better it's worth recompiling ffmpeg for [11:09:39 CEST] <DogTheFrog> I am running CentOS 7.3 [11:09:39 CEST] <Nacht> cheers furq [11:10:41 CEST] <furq> DogTheFrog: how are you distributing the stream [11:12:33 CEST] <DogTheFrog> i wanna distribute the stream with ffserver [11:13:52 CEST] <furq> you should just be able to connect to ffserver on the remote box directly [11:14:07 CEST] <furq> with that said, ffserver isn't very good, so if it doesn't have to be rtsp then you should maybe use nginx-rtmp [11:15:40 CEST] <DogTheFrog> ok, thanks for your help, i will try that:) [11:26:50 CEST] <Nacht> Are there some more tools to get more insight into an AAC file ? [11:27:18 CEST] <Nacht> Im trying to create an HLS Audio stream using AAC, but it just doesnt want to play in Chrome on Android, while the samle of Apple does [11:28:13 CEST] <furq> does android chrome actually support that [11:28:39 CEST] <furq> apple stuff is pretty anal about standards compliance for hls, so if it works there then there's probably nothing wrong with it [11:29:30 CEST] <Nacht> Well the Apple stream actually plays, and it's true, HLS on android is a drag [11:29:57 CEST] <Nacht> I just can't dig deep enough in de AAC files of theirs to see what differs from them when I make em trough FFMPEG [11:36:12 CEST] <zack_s_> kepstin: I tryed cutting my video exactly at the keyframes: ffmpeg -ss 4.566667 -i 1920x1080_30fps_2minuten.mp4 -vcodec copy -acodec copy -t 24.9 output.mp4 [11:36:24 CEST] <zack_s_> however it doesnt work, the video starts at second 0 [11:36:42 CEST] <zack_s_> and the duration is 30 seconds [11:37:06 CEST] <zack_s_> how can I perform a perfect cut without any problems in a mp4 video, without any reencoding? [11:54:01 CEST] <zack_s_> can anybody help? [12:43:02 CEST] <waterworks> ac_slater: if you are here right now, I managed to fix it and I'm actually convinced it is an ffmpeg bug at this point [12:48:09 CEST] <ArsenArsen> How do I calculate the buffer size needed for an AVFrame so I can allocate and align properly [12:48:28 CEST] <ArsenArsen> Or not never midn [12:48:32 CEST] <ArsenArsen> Mind [13:04:53 CEST] <chrysn> hi, i'm trying to set up files for dash streaming, ahd it left me utterly confused: [13:05:59 CEST] <chrysn> on one hand, http://wiki.webmproject.org/adaptive-streaming/instructions-to-playback-ada… and mozilla documentation indicated that it's nowadays perfectly viable to have just one file per stream, ie. no chunks. [13:06:32 CEST] <chrysn> in practice, the dash reference player at http://dashif.org/reference/players/javascript/v2.5.0/samples/dash-if-refer… lets me play my files only if the complete stream can be loaded in ca. 15 seconds [13:06:41 CEST] <chrysn> and the examples they are providing are all chunked up too. [13:08:02 CEST] <chrysn> trying to understand what ffmpeg is doing to create streamable files, i didn't find the -dash option that is obviously accepted by ffmpeg, but which i didn't find in the documentation [13:08:46 CEST] <chrysn> can you help me shed light on whether this complete workflow is supposed to yield dash-streamable files from an ffmpeg PoV? [13:33:29 CEST] <zack_s_> are GOP and I frames the same? [13:34:35 CEST] <furq> no [13:34:59 CEST] <furq> a gop is the frames between two keyframes [13:35:10 CEST] <furq> including the first keyframe [13:35:52 CEST] <furq> "group of pictures" i.e. a self-contained group as far as the decoder is concerned [13:36:14 CEST] <furq> none of the frames in the group reference or are referenced by any frames outside the group [13:37:20 CEST] <JEEB> :D except with open gop where there can be pictures in decode order that cannot be decoded without previous references, but every picture that comes after RAP in presentation order would be decode'able ;) [13:37:46 CEST] <furq> is open gop a thing worth knowing about any more [13:37:57 CEST] <zack_s_> furq: I want to perfom a cut without re encoding, thats why I think it should work between two I frames, so two GOP [13:38:28 CEST] <JEEB> furq: it actually got better defined in HEVC from which I actually more or less grasped that explanation [13:38:39 CEST] <JEEB> and no idea how much that is used [13:38:41 CEST] <furq> oh [13:38:46 CEST] <furq> i had no idea it was even defined in x264 [13:38:54 CEST] <furq> let alone x265 [13:38:56 CEST] <JEEB> in AVC it was SEI+intra [13:38:59 CEST] <JEEB> which was shitty [13:39:05 CEST] <JEEB> in HEVC they made proper NAL unit types [13:39:05 CEST] <furq> well yeah i mean x264 has an -open-gop switch [13:39:22 CEST] <furq> apparently it's required on bluray because why not [13:39:24 CEST] <JEEB> basically that's why you can't always define a RAP with a single NAL unit [13:39:29 CEST] <JEEB> in AVC [13:39:45 CEST] <JEEB> because if you don't take into mention that SEI you only have an intra picture [13:39:56 CEST] <JEEB> thankfully with HEVC they noticed their mistake :P [13:41:09 CEST] <furq> i'll probably just carry on not using it and not giving a shit about bluray [14:05:10 CEST] <zack_s_> ffmpeg cuts differently depening on the parameter placement [14:05:17 CEST] <zack_s_> ffmpeg -ss 4.566667 -i "ffmpeg-1920x1080_30fps_2min.mp4" -vcodec copy -acodec copy -t 10.0 output.mp4 [14:05:31 CEST] <zack_s_> is not the same with: [14:05:32 CEST] <zack_s_> ffmpeg -i "1920x1080_30fps_2min.mp4" -vcodec copy -acodec copy -ss 4.566667 -t 10.0 output.mp4 [14:06:10 CEST] <zack_s_> for unkown reason both cmd lines, does not cut on the iframe at 4.566667 [14:06:12 CEST] <furq> ss seeks differently depending on whether it's an input or output option [14:06:19 CEST] <zack_s_> the first is one second earlier [14:06:24 CEST] <zack_s_> the other on second later [14:07:19 CEST] <zack_s_> input or output options? [14:07:27 CEST] <zack_s_> furq: what do you mean? [14:07:31 CEST] <furq> before or after -i [14:08:24 CEST] <furq> iirc as an input option it uses the container seek index, as an output option it decodes and uses the frame timestamps [14:09:25 CEST] <watlon80> hey all, is there a good way to profile FFmpeg / filter complex performance (with a release binary)? I'd like to roughly pinpoint my filter processing time and optimize where possible. [14:10:00 CEST] <furq> not that i know of [14:10:06 CEST] <grublet> maybe some kind of verbose option? [14:10:07 CEST] <zack_s_> furq: so what is the right choice? [14:10:10 CEST] <furq> nothing better than just outputting to -f null [14:10:15 CEST] <furq> zack_s_: it depends [14:10:17 CEST] <watlon80> I tried Instruments on OS X, but lacking debug symbols the output is kind of useless [14:10:22 CEST] <furq> this is a nontrivial problem, as you've probably noticed [14:10:33 CEST] <zack_s_> furq: crazy... [14:10:45 CEST] <zack_s_> I just want to cut on i-frames, without re encoding [14:10:48 CEST] <grublet> doesnt ffmpeg have debug symbols? [14:10:55 CEST] <zack_s_> I thought it cannot be that hard [14:11:09 CEST] <watlon80> grublet: the build I got (OS X) doesn't seem to have them [14:11:19 CEST] <grublet> oh ok [14:11:22 CEST] <watlon80> I only see system calls in my call tree [14:11:38 CEST] <grublet> you could build ffmpeg yourself [14:11:39 CEST] <furq> zack_s_: you might want to look at -noaccurate_seek and -seek_timestamp [14:11:48 CEST] <grublet> assuming you know how/want to [14:12:04 CEST] <watlon80> grublet: that's my fallback plan, but there might also be performance differences between debug and release builds [14:12:22 CEST] <grublet> yeah i wouldnt know, never tried building with symbols [14:12:27 CEST] <watlon80> it's just that I have this way complex filter graph and I want to optimize where possible [14:13:09 CEST] <furq> you should get an ffmpeg_debug binary when you build it yourself [14:13:11 CEST] <furq> by default [14:13:16 CEST] <Threads> zack_s_ you still trying to cut frameaccurate with ffmpeg ? [14:13:39 CEST] <zack_s_> Threads: yeah... [14:13:47 CEST] <zack_s_> I have a video, which has every second an iframe [14:14:11 CEST] <zack_s_> closed GOP [14:14:21 CEST] <zack_s_> so this has to work at iframe boundary [14:14:22 CEST] <watlon80> furq: alright, I'll see if I can get it to build on my box [14:15:34 CEST] <watlon80> BTW, minor thingie: channel topic mentions 3.3.1 while 3.3.2 is out (?) [14:16:00 CEST] <furq> durandal_1707: ^ [14:16:58 CEST] <durandal_1707> pay me and i will change it [14:17:22 CEST] <furq> idc my irssi window isn't wide enough to show that bit of the topic anyway [14:17:49 CEST] <grublet> does anyone actually read channel topics? [14:17:53 CEST] <grublet> i never do [14:17:56 CEST] <grublet> well, rarely [14:17:57 CEST] <watlon80> it's front center on the web client [14:17:59 CEST] <furq> i'd rather that bit was replaced with something telling you to paste the command line and full output to pastebin [14:18:05 CEST] <grublet> ^ [14:20:18 CEST] <zack_s_> furq: how does -noaccurate_seek help? [14:21:18 CEST] <watlon80> zack_s_: that should skip only to keyframes (for speed) [14:23:16 CEST] <furq> i didn't say it would help, i said it might [14:27:35 CEST] <zack_s_> does anybody know, how I can do the same with the API? [14:27:47 CEST] <zack_s_> because I need to find the nearest keyframe [14:28:09 CEST] <zack_s_> at a certain time [15:51:56 CEST] <zack_s_> furq: do you know how I can do the same with the API? retrieving the keyframe near a position? [16:38:49 CEST] <kerio> is there a grayscale pixel format where pixels are stored as double [16:38:57 CEST] <durandal_1707> nope [16:41:54 CEST] <shincodex> ERror -135 [16:42:09 CEST] <shincodex> is generally RTSP saying we cant support some protocol within its format [16:42:12 CEST] <shincodex> yar? [16:42:44 CEST] <durandal_1707> yes [16:42:56 CEST] <shincodex> so... so.. [16:43:06 CEST] <shincodex> If i force TCP and say YOUR doin it [16:43:19 CEST] <shincodex> and camera is like mmmmm nope. i only do UDP over RTSP suck it [16:43:25 CEST] <shincodex> then im sucking on error 135 [16:52:03 CEST] <victorqueiroz> Hi [16:52:14 CEST] <victorqueiroz> Can I use ffmpeg in a C project? [16:52:57 CEST] <DHE> yes, license permitting [16:53:47 CEST] <shincodex> i wouldnt use ffmpeg.c though [16:54:07 CEST] <shincodex> maybe the collection lib av stuff [16:57:50 CEST] <victorqueiroz> shincodex: Why not? [16:57:57 CEST] <victorqueiroz> I just need to encode pcm data to ogg file [16:58:52 CEST] <shincodex> so your pulling in all of ffmpeg just for audio? [17:05:01 CEST] <kepstin> if you're just encoding pcm to ogg vorbis, the 'libvorbisfile' should provide a much simpler api and smaller dependency [17:05:48 CEST] <kepstin> or, right, libvorbisfile is decoder only [17:05:56 CEST] <kepstin> even so libvorbis directly isn't super hard to use [17:06:10 CEST] <BotoX> Hi, I'm trying to stream an RTSP stream from an IP camera to youtube (RTMP) [17:06:18 CEST] <DHE> indeed, ffmpeg (unless stripped way down) tends to be a 20 megabyte binary package [17:06:19 CEST] <BotoX> video works fine but audio is choppy and spams errors: https://p.botox.bz/view/raw/1a3af996 [17:07:11 CEST] <BotoX> reencode to aac same issue, -c:a copy audio broken on youtube but no errors in ffmpeg [17:07:20 CEST] <BotoX> so I am assuming something is wrong with the audio of the camera [17:07:25 CEST] <BotoX> but it plays fine in mpv [17:15:23 CEST] <verb5> hello everyone [17:15:34 CEST] <verb5> i need help to create ffmpeg mosaic [17:15:46 CEST] <verb5> 2rows 3x3 [17:17:37 CEST] <verb5> i have tried to follow this tutorial but this is what i get https://pastebin.com/raw/iHW8kniz [17:18:49 CEST] <verb5> any help ? [17:19:37 CEST] <furq> "ac-tex damaged" is a decoder error [17:19:42 CEST] <furq> so presumably your input is broken [17:20:11 CEST] <verb5> how could it be broken it's live stream from mumudvb [17:20:23 CEST] <verb5> i can play the stream [17:21:10 CEST] <victorqueiroz> for pcm to audio.ogg encoding, what library should I use? [17:21:15 CEST] <DHE> no graphical glitches when you watch it? [17:21:43 CEST] <verb5> do you find anything wrong in my command ? https://pastebin.com/raw/idjwxZJ2 [17:21:57 CEST] <verb5> no glitches at all [17:22:50 CEST] <furq> that looks fine, but you should use hstack and vstack instead of overlay [17:22:53 CEST] <furq> !filter hstack [17:22:53 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#hstack [19:02:52 CEST] <Felishia> halp D: [19:03:08 CEST] <Felishia> I has a mp4 file and a ogg file :< [19:03:14 CEST] <Felishia> I want to merge them toguther [19:03:34 CEST] <Felishia> replace the audio from the old videos with the new videos [19:03:45 CEST] <Felishia> sorries I means new audio [19:04:05 CEST] <iranen> same lenght? [19:09:38 CEST] <Felishia> iranen, yes c: [19:09:44 CEST] <Felishia> I just fixed the audio [19:15:21 CEST] <Felishia> :< [19:15:48 CEST] <relaxed> which file has the audio you want and which has the video? [19:17:44 CEST] <relaxed> Felishia: ^^ [19:21:52 CEST] <Felishia> relaxed, one.mp4 and one-equalized.ogg [19:22:50 CEST] <Felishia> ah I got it [19:22:56 CEST] <Felishia> but the video only plays in vlc [19:23:00 CEST] <Felishia> anyway [19:31:27 CEST] <relaxed> try, ffmpeg -i video -i audio -map 0:v -map 1:a -c copy output.mkv [20:12:20 CEST] <chrysn> regarding my questions of 13:05 CEST: they've been resolved by not messing up the sequence of the substreams (and updating the documentation); things appear to work fine with unchunked dash files generated out of ffmpeg, just the -dash option appears to be undocumented. [20:18:42 CEST] <maziar> I have too many TS but my m3u8 file is broken and its empty how to fix it [20:37:11 CEST] <maziar> my M3U8 file is broken, how can i create a new M3U8 from my TS ? [20:37:48 CEST] <DHE> umm... copy the streams into a new hls instance? [20:46:13 CEST] <maziar> DHE you are talking to me ? [20:47:07 CEST] <DHE> maziar: yeah [20:47:46 CEST] <maziar> DHE , no, somebody just remove it [21:20:58 CEST] <maziar> my M3U8 file is broken, how can i create a new M3U8 from my TS ? [21:24:56 CEST] <llogan> A simple example could be "ffmpeg -i input.ts output.m3u8" but you didn't really provide much info or requirements, etc. [21:27:22 CEST] <victorqueiroz> Hi. To encode pcm into audio.ogg. What ffmpeg library should I use? I'm developing a C project [21:29:29 CEST] <llogan> libavformat, libavcodec [21:30:47 CEST] <llogan> and possibly libavfilter and libavutil depending on what you want to do. see stuff in doc/examples [23:02:33 CEST] <JodaZ> maziar, M3U8 is a very simple format, in its most basic form it has #EXTM3U in the first line and the segment filenames.ts in order in the following lines [23:03:13 CEST] <maziar> JodaZ I know that, but how can I mention time, for 10000 TS files? ! [23:03:29 CEST] <JodaZ> i don't think you need to [23:04:25 CEST] <DHE> traditionally each segment is of fixed length, in which case you can just assume the same number over and over again. failing that, algorithmically running ffprobe to measure it also works [23:04:55 CEST] <DHE> or, concatenate all the .ts files into a single huge file (piping is fine) and have ffmpeg regenerate the whole m3u8 is also an option, resources permitting [23:05:20 CEST] <DHE> this effectively regenerates the stream from scratch using the original stream (or what's left of it) as the source [23:05:35 CEST] <JodaZ> setting a ext-x-targetduration might help some players with seeking [23:05:58 CEST] <JodaZ> otherwise timing all files with ffprobe i guess? [23:06:27 CEST] <JodaZ> concatenating all files and using copy codecs is basically as fast as copying them [23:07:48 CEST] <maziar> DHE what do you mean, how should I do that [23:08:46 CEST] <DHE> maziar: assuming all the files are named in a sortable order, I'd do something like: cat /path/to/*.ts | ffmpeg -f mpegts -i - -c copy -f hls [-hls_options_here] regenerated.m3u8 [23:09:22 CEST] <DHE> the notion that the inputs and outputs are in different directories may make sense here. I imagine a bit of prep work is required [23:10:22 CEST] <maziar> DHE my ts file order is ok on M3U8 but it doesn't work [23:11:14 CEST] <maziar> DHE https://pastebin.com/QvPVgzzh [23:12:19 CEST] <maziar> DHE but in original file there is 2500 line [23:22:53 CEST] <JodaZ> maziar, do the few ts files that are in there work as it is? [23:24:10 CEST] <maziar> JodaZ it is begin with 1080_17141000.ts and end with 1080_1714999 , its means that there are 2234 files [23:24:29 CEST] <maziar> I past a few of them to show you the order of files and files name [23:24:38 CEST] <DHE> maziar: if you're doing this by hand, add #EXTINF:10.00, (including the comma) just above each .ts file. this of course assumes each file is 10 seconds long exactly [23:25:18 CEST] <JodaZ> maziar, actually there should be 3999 files then [23:25:54 CEST] <maziar> DHE there is 2234 line, show should I add this among of #EXTINF:10.00, [23:26:04 CEST] <JodaZ> see if you can play the .ts files as they are [23:26:08 CEST] <JodaZ> like by themselfes [23:26:28 CEST] <maziar> is there any way to create a M3U8 from this TS's ? [23:26:57 CEST] <JodaZ> your m3u8 should play [23:27:05 CEST] <JodaZ> check if the ts by themselfes play [23:27:22 CEST] <DHE> I adequately described how to use it already [23:39:26 CEST] <maziar> DHE thankyou Im checking it [00:00:00 CEST] --- Sat Jun 17 2017

1 0

ffmpeg-devel.log.20170615
by burek 16 Jun '17

16 Jun '17

[00:09:37 CEST] <J_Darnley> FFS! This shit is impossible to get working. It's not the same as C. It's not the same as MMX. [00:09:53 CEST] <cone-862> ffmpeg 03Mark Thompson 07master:88a2e4504d18: hevc: Fix scaling list prediction delta for the 32x32 inter matrix [00:10:27 CEST] <durandal_1707> J_Darnley: really? [00:11:43 CEST] <J_Darnley> As far as I can tell [00:12:27 CEST] Action: J_Darnley will slap together a commit and push that somewhere [00:12:32 CEST] <nevcairiel> did you guys ever figure out why mmx and C differ? That alone seems like a bad sign of the hacks to me [00:13:22 CEST] <J_Darnley> No [00:13:23 CEST] <kierank> no questioning old neckbeard code nevcairiel! [00:13:53 CEST] <J_Darnley> I never went looking for emails from 2002 which I think is where the 16383 comes from. [00:16:54 CEST] <J_Darnley> If you only skimmed the discussion earlier I think it could be summed up as "16383 was a better match for other encoders at the time" [00:18:45 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:900fe8ee5d17: avcodec/dnxhdenc: Assert that frame size is not assigned an error code [00:18:46 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:0a87be404ab7: avcodec/mpeg4videodec: Fix integer overflow in num_sprite_warping_points=2 case [00:18:47 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:12245ab1f677: avcodec/mpeg4videodec: Check sprite delta upshift against overflowing. [00:20:11 CEST] <iive> J_Darnley: I thought that the C version remained with 16384 has been kept in C code, because it is done by shift and is faster (with int) [00:20:29 CEST] <iive> on mmx it doesn't matter, since it uses mul anyway. [00:20:54 CEST] <iive> ops... [00:21:06 CEST] <J_Darnley> In the "dc only" bit it will use 16384 but in the actual idct it will use 16383 [00:21:23 CEST] <iive> c or mmx ? [00:22:13 CEST] <cone-862> ffmpeg 03James Almer 07master:37388b119cf8: checkasm: add a checkasm_checked_call function that doesn't issue emms [00:22:14 CEST] <cone-862> ffmpeg 03James Almer 07master:5b10f484e2b3: checkasm: add float_dsp tests [00:22:15 CEST] <cone-862> ffmpeg 03James Almer 07master:e53c9065ca08: avutil/tests: remove float_dsp test [00:22:21 CEST] <J_Darnley> Both I think. [00:27:37 CEST] <iive> so... if both do the same, what causes the difference [00:27:58 CEST] <BBB> J_Darnley: wait I thought with my changes it matches? [00:28:02 CEST] <J_Darnley> I wish I knew [00:28:05 CEST] <BBB> J_Darnley: or is there another issue that I caused? [00:28:33 CEST] <J_Darnley> BBB: dct is the same on all 3 tests [00:28:44 CEST] <BBB> ok, so thats promising, right? [00:28:44 CEST] <J_Darnley> but I get an error with a vsynth2 test [00:28:48 CEST] <J_Darnley> Yes! [00:28:52 CEST] <BBB> hm... [00:29:28 CEST] <BBB> can you set aborts in each of put, add and regular idct to see which ones it calls? [00:29:39 CEST] <BBB> or breakpoints [00:29:43 CEST] <BBB> I guess I can do it myself as well [00:29:47 CEST] <BBB> which vsynth2 test? [00:30:47 CEST] <J_Darnley> I think it was fate-vsynth1-wmv1 [00:30:55 CEST] <J_Darnley> (so not vsynth2) [00:33:26 CEST] <iive> J_Darnley: so... there is difference between C and MMX version and you don't know what causes it. [00:33:53 CEST] <iive> and there is difference between MMX and SSE2 version and you don't know what causes that either? [00:34:07 CEST] <BBB> do you know from the multiple commands it executes (see V=1) whether its the encode or decode that changed? [00:34:22 CEST] <J_Darnley> I think it must be the decode [00:34:32 CEST] <J_Darnley> the input video is generated [00:34:56 CEST] <J_Darnley> oh but the encoder needs to decode to produce ref frames [00:35:45 CEST] <iive> J_Darnley: can you setup a bit of glue code, that uses both mmx and sse idct and checks if their result differ? [00:35:45 CEST] <J_Darnley> so in that case... both? [00:36:03 CEST] <J_Darnley> that is libavcodec/tests/dct [00:36:21 CEST] <J_Darnley> It doesn't directly compare, that is out job [00:36:31 CEST] <J_Darnley> I guess I could modify it. [00:36:35 CEST] <iive> J_Darnley: do you have a specific input that causes a difference [00:36:53 CEST] <iive> you don't need statistics, you need a specific input. [00:36:54 CEST] <J_Darnley> Not with tool [00:37:22 CEST] <BBB> J_Darnley: can you run md5 on the generated file to see whether encode changed before/after your changes? [00:37:28 CEST] <BBB> thats actually helpful to know [00:38:22 CEST] Action: J_Darnley swears [00:38:26 CEST] <J_Darnley> In a moment [00:51:44 CEST] <BBB> lol [00:51:49 CEST] <BBB> I think youre pretty close [00:51:58 CEST] <BBB> if wmv failed, that means its probably a type check missing somewhere [00:52:05 CEST] <BBB> but it suggests the larger body of work is finished [00:52:39 CEST] <jkqxz> wm4: The obvious change is not going to work because of the videotoolbox_pixfmt thing (which looks like some sort of crazy hack). I think it needs someone who can actually compile it to look. [00:53:22 CEST] <wm4> what thing? [00:53:53 CEST] <jkqxz> <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg_opt.c;h=bb6001f534d0c…> [00:54:11 CEST] <jkqxz> Which gets to <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg_videotoolbox.c;h=e903…>. [00:54:19 CEST] <wm4> oh that [00:54:29 CEST] <wm4> you can just set the format on the hwframes ctx [00:54:36 CEST] <jkqxz> So it's -hwaccel_output_format except using the native name? [00:54:45 CEST] <jkqxz> Or something else. [00:54:59 CEST] <jkqxz> Ha, does that need init_hw_frames then? [00:55:06 CEST] <wm4> yeah I think it uses a native name [00:55:12 CEST] <wm4> hm probably [00:55:28 CEST] <wm4> videotoolbox is pretty "special" in that it can output any format, and the decoder/whatever converts [00:55:43 CEST] <wm4> so this is atypical [00:56:03 CEST] <wm4> (another +1 for VT as standalone decoder instead of hwaccel) [00:57:19 CEST] <nevcairiel> wasnt the problem with that that the VT API is dumb as fuck and requires a lot of code, including re-ordering? [01:09:23 CEST] Action: J_Darnley facepalms [01:09:42 CEST] <J_Darnley> I will address *that* bug later [01:10:29 CEST] <wm4> nevcairiel: yes, we'd have to do reordering ourselves [01:10:32 CEST] <J_Darnley> Okay, good. Back on course [01:11:12 CEST] <nevcairiel> you would also end up duplicating all sorts of SEI handling and whatnot, which is why hwaccels are so nice, you get all of that for free [01:11:25 CEST] <wm4> videotoolbox is really a hysteric API... it's neither hwaccel not full decoder, and just makes your life harder for no reason at all [01:11:35 CEST] <iive> J_Darnley: do you have a debugger where you can step through the asm code and see the registers? [01:11:43 CEST] <J_Darnley> Yes, gdb [01:12:09 CEST] <iive> does gdb have a mode where it outputs the changed register automatically? [01:12:31 CEST] <J_Darnley> Maybe, I don't know it though. [01:12:57 CEST] <iive> i've looked and i haven't found it. [01:13:15 CEST] <iive> last time i tried ddd also didn't had it. [01:14:42 CEST] <iive> J_Darnley: you might want to give a try to `edb` it is assembler oriented and i find it quite useful, despite needing some polish. [01:15:12 CEST] <J_Darnley> noted [01:15:14 CEST] <iive> i'm also not sure if it supports avx and ymm, but it works for sse [01:15:54 CEST] <J_Darnley> BBB: the encoded video differs [01:16:22 CEST] Action: J_Darnley can't believe that took him 30 minutes [01:16:48 CEST] <J_Darnley> Also, you should use the mpeg2_asm5 branch on my gitlab [01:17:30 CEST] <J_Darnley> It avoids a bug I've got in add/put and has your patch working. [01:17:37 CEST] <kierank> J_Darnley: what was the problem [01:18:02 CEST] <J_Darnley> We don't know yet [01:18:28 CEST] <kierank> ok [01:18:52 CEST] <J_Darnley> But my 30 minute problem was trying to make a clean commit [01:19:13 CEST] <J_Darnley> That didn't make a step backwards [01:22:08 CEST] <kierank> anyway it will make a good blog [01:55:42 CEST] <BBB> J_Darnley: okiedokie, good to know. I will check wmv2enc [01:58:54 CEST] <BBB> oh, not wmv2enc [01:58:56 CEST] <BBB> hm... [02:01:22 CEST] <BBB> J_Darnley: why FF_IDCT_SIMPLE as idct_algo in your assignment? [02:01:28 CEST] <BBB> J_Darnley: the mmx function doesn't [02:02:05 CEST] <J_Darnley> So that it runs more in fate [02:04:00 CEST] <BBB> but its not compatible with FF_IDCT_SIMPLE, I think [02:07:04 CEST] <BBB> (I dont know why, but the mmx function is also not assigned for algo==simple) [02:08:41 CEST] <BBB> its possible that it doesnt have to do much with the idct itself, but rather with the fact that perm_type is not default for the non-C version [02:08:43 CEST] <BBB> I dont know [02:19:39 CEST] <J_Darnley> Can I ask you to revert that and then test fate? [02:25:47 CEST] <philipl> jkqxz: So what's the generic hwaccel syntax I should try for cuda? Is it documented in your changes? [02:33:10 CEST] <J_Darnley> I get no errors in that case. But I also got no errors on fate before michaelni made us go looking for problems. [02:41:10 CEST] <philipl> \jkqxz: Looks like something like "ffmpeg -y -hwaccel cuvid -hwaccel_output_format cuda -c:v h264_cuvid -i sample.mp4 -c:v h264_nvenc -map 0:0 -f rawvideo /dev/null" [02:44:17 CEST] <J_Darnley> What the fuck have I been doing this week? [02:44:33 CEST] <J_Darnley> Wasting everyone's time by the look of it. [02:47:20 CEST] <philipl> BtbN, jkqxz: https://github.com/philipl/FFmpeg/commit/951e804c33bf77d87c67e11b9354c3c267… [03:10:31 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:1cb4ef526dd1: avcodec/hevc_refs: Check nb_refs in add_candidate_ref() [03:10:32 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:bc4067446207: avcodec/hevcdec: Check nb_sps [03:11:54 CEST] <J_Darnley> Christ. I think I might have finished. [03:12:07 CEST] <J_Darnley> I do have a bug in my add function. [03:12:41 CEST] <J_Darnley> the sse2 branch didn't store correctly [03:13:13 CEST] <J_Darnley> I added a new fate test based on that matrixbench clip michaelni pointed out. [03:13:59 CEST] <J_Darnley> That does manage to get identical output for C, MMX, and now SSE2 [03:17:04 CEST] <J_Darnley> Maybe this week hasn't been wasted [03:21:03 CEST] <J_Darnley> Pull my mpeg2_asm5 branch and make fate-simpleauto [03:21:11 CEST] <J_Darnley> Good night [11:21:26 CEST] <cone-854> ffmpeg 03Paul B Mahol 07master:9b667f609c50: avfilter/af_headphone: fix possible memory leaks on failure [12:10:15 CEST] <BBB> should --enable-libfdk-aac enable AAC de/encoding via libfdk-aac [no] disappear from configure? [12:10:20 CEST] <BBB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=e3941f9dfd79557a… [12:13:44 CEST] <BBB> J_Darnley: I just noticed your msgs yesterday, good idea to add a fate test [12:14:03 CEST] <BBB> J_Darnley: does the fate test execute all three (idct, idct_put and idct_add) versions of the function? [12:14:35 CEST] <BBB> J_Darnley: and a potential problem may be that the fate test does not give the same results across platforms ... [12:20:27 CEST] <J_Darnley> It does do both add and put. If forgot to check whether the plain idct is used. [12:25:13 CEST] <J_Darnley> Ah. A quick check suggests that it does not use the plain idct. [14:33:59 CEST] <atomnuker> durandal_1707: bored? there's still an atrac9 decoder to write [14:39:06 CEST] <JEEB> :D [14:39:23 CEST] <JEEB> I had a dump of the reference binary somewhere [17:06:04 CEST] <BBB> J_Darnley: hurray [17:06:10 CEST] <J_Darnley> FUCK HOW THE FUCK DID I DROP THAT FUCKING CHANGE GOD FUCKING DAMMIT [17:06:26 CEST] <BBB> hey hey hey now now now [17:06:32 CEST] <BBB> hush [17:06:43 CEST] <BBB> I think dc-only is a fine name btw [17:06:44 CEST] <J_Darnley> I somehow dropped the 32 byte stack space change [17:06:56 CEST] <BBB> in a 2d context, dc is top/left [17:07:00 CEST] <BBB> in a 1d context, dc is just the first [17:07:01 CEST] <RiCON> BBB: what's wrong with fdk-aac? [17:07:06 CEST] <BBB> it was dropped [17:07:12 CEST] <BBB> but the configure option is still there [17:07:16 CEST] <RiCON> it was? [17:07:19 CEST] <BBB> I believe so [17:07:29 CEST] <RiCON> i don't believe so [17:07:35 CEST] <BBB> oh wait its still there [17:07:36 CEST] <BBB> nevermind [17:07:38 CEST] <BBB> <- stupid [17:07:41 CEST] <RiCON> faac and aacplus were [17:07:58 CEST] <BBB> aha ok [17:08:27 CEST] <atomnuker> michaelni: why does ffv1 have a max packet size? [17:08:34 CEST] <BBB> I believe next, we should drop support for all hevc decoders and deprecate hevc :-p [17:08:39 CEST] <BBB> hevc encoders* [17:08:52 CEST] <atomnuker> it breaks encoding of high resolution (e.g. 15000x9000) images [17:09:38 CEST] <atomnuker> and ffv1 and png are the only ones capable of lossless rgb I think [17:09:50 CEST] <atomnuker> (and png is slow and very inefficient) [17:10:35 CEST] <RiCON> doesn't x264 do lossless rgb too? [17:10:38 CEST] <BBB> J_Darnley: is simple_auto maybe a poor fate test because its results will differ from arch to arch? [17:15:38 CEST] <BBB> J_Darnley: the rest looks good to me, nice! [17:15:48 CEST] <BBB> J_Darnley: I look forward to the angry blog post :D [17:17:46 CEST] <J_Darnley> I will endavour to leave out the swearing rant sections. [17:18:04 CEST] <J_Darnley> And I forgot the message-id for that email. [17:18:08 CEST] <BBB> its ok [17:18:23 CEST] <BBB> maybe you shouldnt blog, but do a VDD talk about this work [17:25:05 CEST] <jkqxz> But the swearing rant sections are the best bits! [17:26:39 CEST] <jkqxz> On the subject of swearing rants, do people actually approve of the NV12 warning patch or not? [17:29:36 CEST] <BBB> Im indifferent to it [17:29:39 CEST] <BBB> I think its fine [17:43:19 CEST] <cone-959> ffmpeg 03Tyler Jones 07master:5a2ad7ede33b: vorbisenc: Separate copying audio samples from windowing [17:43:20 CEST] <cone-959> ffmpeg 03Tyler Jones 07master:f57f66518359: vorbisenc: Apply and output correct length window and mdct [17:43:21 CEST] <cone-959> ffmpeg 03Tyler Jones 07master:752dd1952a7b: vorbisenc: Stop tracking number of samples per frame [18:10:55 CEST] <kierank> BBB: should we submit it to demuxed or is it too technical for them? [18:11:20 CEST] <BBB> I thought the goal of demuxed was to be technical? :-p [18:11:26 CEST] <BBB> peloverde: ^^ [18:20:31 CEST] <kierank> I've submitted something myself but in a different area (uncompressed video transport) [18:59:10 CEST] <philipl> jkqxz: I lost track - what's the plan for not having to specify the output format to ffmpeg to make transcoding work without download/upload by default? [19:01:57 CEST] <jkqxz> No plan yet. I was wondering whether we could do it by detecting fake hwaccels, or maybe there could be a new flag in the HWAccel table? [19:04:18 CEST] <wm4> fake hwaccels? wut? [19:33:32 CEST] <cone-959> ffmpeg 03Rostislav Pehlivanov 07master:b52b398c30a7: vc2enc: decrease default strictness level [19:48:21 CEST] <michaelni> atomnuker, the max packet size is the worst case size, its smaller in version > 3. It could be reduced in older versions if some reallocation support is added [19:49:02 CEST] <michaelni> it would be trivial to realloc if it wasnt for the slice / thread code [19:49:03 CEST] <atomnuker> but it can be exceeded, so its not the worst case [19:49:23 CEST] <michaelni> it should not be exceeded [19:49:33 CEST] <atomnuker> so its a bug then? [19:49:56 CEST] <michaelni> dunno, but sounds like one, how can it be reproduced? [19:50:14 CEST] <atomnuker> "[ffv1 @ 0x3770f00] Cannot allocate worst case packet size, the encoding could fail" [19:50:29 CEST] <michaelni> "could fail" doesnt mean it does fail [19:50:30 CEST] <atomnuker> makes it sound like I'm running out of memory [19:50:40 CEST] <atomnuker> "Assertion bytes < (1 << 24) failed at libavcodec/ffv1enc.c:1216" [19:50:53 CEST] <michaelni> assert failure is always a bug [19:51:13 CEST] <nevcairiel> worst case is quite huge, it could overflow 32-bit, maybe you should try a 64-bit build [19:52:23 CEST] <atomnuker> ./ffmpeg_g -f rawvideo -s 14027x9924 -pix_fmt rgb24 -i /dev/urandom -frames 1 -c:v ffv1 -f null - [19:52:31 CEST] <atomnuker> this always fails here [19:52:40 CEST] <nevcairiel> worst case for ffv1 1 and 3 is w*h*37*4 [19:52:45 CEST] <nevcairiel> so thats 20602184304 bytes [19:53:15 CEST] <atomnuker> happens with -level 4 as well [19:53:25 CEST] <nevcairiel> its w*h*3*4 for 4 [19:54:01 CEST] <nevcairiel> that should in theory fit into an int though [19:55:29 CEST] <atomnuker> seems like it doesn't though, it exceeds INT_MAX - 64 [19:57:10 CEST] <nevcairiel> its still a huge buffer and easy to run out of memory from [19:57:51 CEST] <atomnuker> you might be right actually [19:58:10 CEST] <atomnuker> didn't realize the worst case packet is *that* big [19:58:37 CEST] <atomnuker> 19 gigabytes, damn [20:00:01 CEST] <atomnuker> I think there should be an option which insteads uses a lower worst case packet size and instead reallocs if the buffer runs out, though it'll be slower and messier [20:01:24 CEST] <atomnuker> or maybe something like running the encoder once to determine the exact buffer size needed [20:04:49 CEST] <nevcairiel> at least 4 has a PCM mode that greatly reduces the worst case [20:06:32 CEST] <nevcairiel> and you could probably reduce the worst case further if you made it dependent on the pixel format used, instead of a generic value for all [20:27:56 CEST] <michaelni> yes, there also seems to be a bug in slices with huge resolutions [22:50:03 CEST] <BBB> wbs: do you have any recollection what type of decoding speed I could expect for regular content at typical resolutions using e.g. 1 core on aarch64? [22:50:16 CEST] <BBB> wbs: e.g. 10fps? 50fps? 5000 fps? [22:53:46 CEST] <atomnuker> on an odroid c2 for a standard 1080p24 bluray m2ts I get around 14fps with 1 thread [22:54:39 CEST] <atomnuker> divide that by 4 or 5 for a raspberry pi 3 even if you somehow get some aarch64 image running [22:58:00 CEST] <atomnuker> 10 fps now after letting it run for 5 minutes [22:58:59 CEST] <atomnuker> no audio decoding, just ~30mpbs h264 (or were you interested in vp9?) [23:01:27 CEST] <durandal_1707> atomnuker: filter status asap! [23:03:07 CEST] <atomnuker> nothing new since tuesday, but I'll have something to review by sunday [23:03:49 CEST] <atomnuker> durandal_1707: how is the ambisonics gsoc going? [23:05:29 CEST] <durandal_1707> well, its mainly figuring proper stuff for making decoder ambidonic regarding various speakers layouts [23:06:48 CEST] <atomnuker> isn't it going to only support outputting to headphones initially? [23:07:14 CEST] <durandal_1707> that would be too trivial to do [23:08:55 CEST] <J_Darnley> Did someone recently flush the moderation queue for ffmpeg-user? [23:09:15 CEST] <durandal_1707> why? [23:11:37 CEST] <J_Darnley> I just noticed a few old emails that were marked unread [23:22:17 CEST] <BBB> atomnuker: vp9 obviously :-p [23:22:39 CEST] <BBB> atomnuker: all these devices have hw h264 decoders ;) [23:24:11 CEST] <TD-Linux> unfortunately there's a lot of variance for aarch64... the a57 has double the throughput per-clock as the a53, for example [23:31:13 CEST] <atomnuker> BBB: around 24 fps for a 1080p30 at ~3.5Mbps youtube rip on a single thread [23:32:06 CEST] <atomnuker> for a month old 3.3 release [23:32:21 CEST] <BBB> wow :) [23:33:14 CEST] <JEEB> atomnuker: vp9? nice [23:34:17 CEST] <atomnuker> will try git master if I can get it to build without much trouble [23:34:41 CEST] <atomnuker> to hell with gas and that damned script [23:35:23 CEST] <jamrial> oh neat, we have aarch64 vp9 asm [23:35:39 CEST] <BBB> wbs is a hero [23:44:04 CEST] <BBB> atomnuker: thanks for testing [00:00:00 CEST] --- Fri Jun 16 2017

1 0

ffmpeg.log.20170615
by burek 16 Jun '17

16 Jun '17

[00:04:55 CEST] <alexpigment> has anyone worked enough with H264_QSV (Intel Quick Sync) to know how to work around blocky/glitchy artifacts during fast motion and crossfades? [00:05:33 CEST] <kepstin> alexpigment: not really much you could do about it, hardware encoders are kinda fixed. Just throw more bitrate at it. [00:05:34 CEST] <alexpigment> i can bump up the quality factor even more, but at a certain point, it's like i'm throwing more bits at the whole thing to fix problems with just a small handful of moments [00:06:01 CEST] <alexpigment> kepstin: hmmm, ok [00:06:07 CEST] <kepstin> if you can, switch to using a software encoder instead ;) [00:06:39 CEST] <alexpigment> well, this will be an alternative option, not the only one [00:07:02 CEST] <alexpigment> this is the "you agree to trade off quality for speed because you bought a crappy CPU" option [00:07:23 CEST] <alexpigment> having said that, the tradeoffs for nvidia aren't bad at all [00:07:57 CEST] <alexpigment> as long as you don't need any sort of very specific specs [00:09:29 CEST] <kepstin> I actually just picked up a pascal-based card for some other stuff, I should try poking at the hardware encoder on it. [00:16:02 CEST] <alexpigment> kepstin: yeah, i think you'll be surprised [00:16:30 CEST] <alexpigment> i've been using a pascal card for a few months now [00:18:21 CEST] <kepstin> (that said, the card I have is the GT 1030, and I don't actually know if it has nvenc block present) [00:18:40 CEST] <JEEB> the only mode I've used with my 1080 is the 4:4:4 lossless :D [00:23:54 CEST] <alexpigment> kepstin: the 1030 looks like it's a true pascal rather than a rebrand [00:24:20 CEST] <alexpigment> nvidia is notorious for just rebranding a 430 as a 520 then as a 610 [00:24:36 CEST] <alexpigment> but it looks like they haven't done that (yet) with their 1000 series [00:24:37 CEST] <kepstin> yes, but it's GP108, a different die from any of the other cards. [00:25:00 CEST] <alexpigment> true, but i suspect it'll still be good [00:25:17 CEST] <alexpigment> most of what i notice between the generations is just speed [00:25:25 CEST] <alexpigment> so even if it's a little slower, i don't think you'll notice [00:25:28 CEST] <kepstin> i dunno, in their previous low-power 'gt' card - the gt 730 - apparently they didn't include the nvenc stuff either? :/ [00:25:37 CEST] <alexpigment> hmm [00:25:44 CEST] <alexpigment> i just tested a 710 a few minutes ago [00:25:56 CEST] <alexpigment> but maybe the 730 is a double rebrand of a 550 or something [00:26:37 CEST] <alexpigment> yeah, the DDR3 128-bit version of the 730 is a Fermi rebrand rather than Kepler [00:26:46 CEST] <kepstin> oh, that's confusing. there's 3 differen cards named 'gt 730' [00:26:52 CEST] <alexpigment> yeah [00:27:01 CEST] <alexpigment> like i said, nvidia is notorious for htis [00:27:03 CEST] <alexpigment> *this [00:27:04 CEST] <kepstin> there's gf108, and 2 differentgk208 [00:27:11 CEST] <kepstin> so it could be either fermi or kepler [00:27:33 CEST] <alexpigment> i was trying to help a coworker figure out if their 640 would do nvenc - there are FOUR versions of that card [00:27:45 CEST] <alexpigment> well, the codename tells you what it is [00:28:00 CEST] <alexpigment> "GF108" = Fermi, "GK208" = Kepler [00:28:08 CEST] <alexpigment> the second letter always corresponds with the architecture fwiw [00:28:35 CEST] <alexpigment> perhaps that's obvious information, but it does take a little leap to connect the two [00:29:09 CEST] <kepstin> yeah. at least the quadro naming scheme makes it a bit more obvious [00:29:17 CEST] <kepstin> i guess since people in that market care more abou tit [00:29:23 CEST] <alexpigment> yeah they use the first letter, right? [00:29:36 CEST] <kepstin> yeah [00:29:39 CEST] <DHE> I have a quadro whose code is GM107GL (Maxwell?) [00:30:20 CEST] <kepstin> well, apparently the quadro stuff was weird with the 'K' series [00:30:34 CEST] <kepstin> GM107 could be a K1200 or K2200 :/ [00:31:30 CEST] <DHE> there is a bit of ambiguity because there's 2 generations named maxwell [00:31:44 CEST] <alexpigment> yeah, maxwell is confusing [00:32:01 CEST] <alexpigment> still, the rebrands that nvidia does are the main source of confusion [00:32:26 CEST] <alexpigment> if you buy anything below a _50, you have to look it up to know what you're getting [00:32:42 CEST] <kepstin> at least so far, every single desktop 10xx card has been actually pascal, fwiw [00:32:54 CEST] <alexpigment> yeah [00:32:58 CEST] <alexpigment> that's what the wiki says [00:33:03 CEST] <alexpigment> which is why i think your 1030 will be fine [00:33:24 CEST] <alexpigment> anyway, i'm heading out [00:33:33 CEST] <alexpigment> (and screw quick sync) [00:36:18 CEST] <kepstin> annoying that https://developer.nvidia.com/video-encode-decode-gpu-support-matrix doesn't list the consumer models, only quadro & tesla [00:37:06 CEST] <DHE> well, you can assume the number of chips is 1 and the capabilities are basically grouped by chipset/generation [00:37:12 CEST] <kepstin> (and there's no quadro cards with gp108, so I can't get anything from that chart) [00:38:07 CEST] <DHE> also max sessions = 2 [00:38:16 CEST] <kepstin> but yeah, if it has the same encoder block config as gp107, it'll be nice. 1 nvenc chip, 2 sessions in that case [00:39:14 CEST] <kepstin> so the question is basically, "did nvidia drop the encoder block from gp108 to make the die smaller/cheaper?" and I don't know the answer to that yet [00:40:36 CEST] <DHE> maybe they dropped it from the low-end cards, like 1030 (does such a thing exist?) [00:41:05 CEST] <kepstin> I have a Geforce GT 1030 (GP108), that's what this whole discussion is about ;) [00:50:17 CEST] <Tatsh> honestly though, nvenc is fast and nice but the quality is lower overall [00:51:07 CEST] <DHE> that's what it offers. you can have a fast, no-CPU h264 encoder but quality suffers. "slow" mode helps a bit, but it's no match for x264. [00:51:23 CEST] <Tatsh> it's good enough for live streaming [00:51:37 CEST] <Tatsh> for most things [00:51:47 CEST] <Tatsh> like, webcam crap [00:52:50 CEST] <DHE> video game streamers love it [00:53:16 CEST] <Tatsh> but video game streamers aren't videophiles [00:53:58 CEST] <Tatsh> and also the viewers are mostly not (audio|video)philes of any kind [00:54:08 CEST] <Tatsh> otherwise they'd demand lossless audio :) [00:57:43 CEST] <kepstin> hmm, so I need anything other than the libraries from the nvidia drivers to work? (or does it need to run in an X display?) [00:58:04 CEST] <kepstin> I'm just getting a "Cannot init CUDA" when I try to use h264_nvenc over ssh [00:58:27 CEST] <Tatsh> it doesn't need X [00:58:53 CEST] <Tatsh> you need nvidia-cuda libraries installed [00:59:05 CEST] <Tatsh> https://developer.nvidia.com/nvidia-video-codec-sdk [00:59:24 CEST] <Tatsh> i have cuda-sdk, video_sdk and the drivers [01:00:33 CEST] <kepstin> looks like the linux nvidia drivers package includes libcuda et all, and the sdk only has headers (which ffmpeg has internal copies of anyways, iirc) [01:01:45 CEST] <kepstin> https://gist.github.com/kepstin/8f0fad41842bb923da8709267fed0f9d is what I'm seeing [01:02:18 CEST] <kepstin> hmm, that has a bad pix_fmt, but even if I fix that, same thing. [01:06:26 CEST] <jkqxz> kepstin: I believe that the 1030 doesn't have encode at all, just decode. So, yeah, I think you're doomed. [01:06:38 CEST] <kepstin> yeah, that's what it's looking like [01:07:20 CEST] <kepstin> owell, I didn't really have a use for it anyways; just wanted to experiment. If I want to encode some video, that's what the ryzen is for ;) [01:07:32 CEST] <jkqxz> I don't think nvndia has said anything explicitly about it, though, so it's possible that the problem is somewhere else (drivers not yet updated, say). [01:09:19 CEST] <kepstin> although I'm guessing def. a driver problem here, because it should at least be initializing cuda before telling me that there's no gppus with encoders. [01:09:29 CEST] <kepstin> meanwhile the whole cuda init is just failing [01:10:23 CEST] <kepstin> unless I'm reading the code wrong [01:13:31 CEST] <kepstin> the decoder isn't working either [01:30:59 CEST] <alexpigment> kepstin: did you reinstall the most recent drivers? [01:31:34 CEST] <alexpigment> oh you're on linux - nm [01:31:42 CEST] <alexpigment> i've only tested windows [01:32:57 CEST] <livingbeef> I have an image sequence and I'd like to generate a heatmap with changes - either animated (accumulated chages over N images), or just "sum". Any idea of something like that can be done with ffmpeg? [01:33:45 CEST] <livingbeef> I know I can generate gif with the trasparency optimization, which gives me the layers which only contain chages. I guess that might help. [01:36:08 CEST] <tapeman> I'm trying to do some captures from my v4l2 device, and changing the x264 profile from fast to medium seems to cause alsa xruns, which show up as audio dropouts- any ideas? https://pastebin.com/44dGQCg2 [01:37:12 CEST] <DHE> you can see the first speed is basically 1.0x (shows 0.992x), but the second is all over the place starting at 0.5x [01:37:17 CEST] <DHE> your CPU isn't up to medium [01:40:26 CEST] <tapeman> that's weird- I would think an i7-2600 would be up to handling SD h264- am I doing something wrong here? [01:42:30 CEST] <furq> it's probably not the issue, but why are you using ac3 [01:42:39 CEST] <furq> it sucks and also the builtin ac3 encoder probably isn't any good [01:44:49 CEST] <tapeman> for mp4, I thought my options were ac3 or mp3- is one much better than the other? [01:44:59 CEST] <furq> aac [01:45:22 CEST] <furq> although mp3 is better than aac [01:45:24 CEST] <furq> er [01:45:26 CEST] <furq> although mp3 is better than ac3 [01:45:32 CEST] <furq> aac is better than both [01:46:29 CEST] <tapeman> okay- I'll try that. Is there any kind of documentation/guideline on thread_queue_size? It feels like I'm randomly putting numbers into that [01:48:31 CEST] <DHE> all params are documented in https://ffmpeg.org/ffmpeg-all.html (warning: large file), though that option is a big vague. [01:49:03 CEST] <DHE> basically a distinct thread does the ALSA work and a queue passes it up to the main ffmpeg thread. [01:50:26 CEST] <DHE> sufficiently large values will deal with the issue, but only as long as the recording is short-ish [01:50:51 CEST] <furq> you can probably ignore the "consider increasing thread_queue_size" warning [01:51:07 CEST] <furq> i get that all the time with vapoursynth and increasing it doesn't do anything [01:54:18 CEST] <DHE> the description just says "packets". how large are packets from the alsa driver? source code looks like it just takes the minimum (whatever that is) [01:54:34 CEST] <DHE> worried it might be something pathetic like 128 samples [01:55:14 CEST] <tapeman> let's assume you're correct- what should I set it to then as a more reasonable setting? [01:56:15 CEST] <DHE> not knowing the units, I'd say try something absurdly large like 10,000 and see how it works. if that still doesn't work, I propose your CPU is still too weak [01:56:27 CEST] <tapeman> okay [01:57:06 CEST] <tapeman> is there anything else about the command that strikes you as weird or unusual? [02:01:01 CEST] <DHE> I'm assuming the hard drive isn't any kind of bottleneck for IO since this is a rawvideo source [02:01:57 CEST] <tapeman> doing 4000 or so seemed to let me use -medium profile, so maybe that was it [02:02:27 CEST] <DHE> what was the final speed multiplier for the medium run? [02:03:10 CEST] <Threads> dumb question alert [02:03:25 CEST] <Threads> possible to do gpu audio encoding ? [02:03:57 CEST] <DHE> not that I'm aware of. Audio encoding isn't that difficult. I can encode AAC in software at ~20x realtime speed [02:04:40 CEST] <furq> there's flaccl [02:04:48 CEST] <furq> i don't know of any lossy encoders [02:05:17 CEST] <tapeman> it looks like .991 [02:05:45 CEST] <DHE> tapeman: that's close enough to realtime that you are probably fine for CPU. just a bad start that caused dropped audio [02:06:18 CEST] <tapeman> thanks so much for your help here! [04:32:13 CEST] <TotallyHuman> I have a mp4 video file which I can't import into Premiere, probably because of variable frame rate. When I convert it in ffmpeg, the audio and video are getting out of sync. I have used these 2 commands: [04:32:20 CEST] <TotallyHuman> ffmpeg -i input.mp4 -c copy -copyts output.mp4 [04:32:26 CEST] <TotallyHuman> ffmpeg -i input.mp4 -c copy -copyts -r 30 output.mp4 [04:32:32 CEST] <TotallyHuman> Could you advise me on how to proceed? [07:18:46 CEST] <rk[ghost]> is there a way to use ffmpeg to cut a strip out of an audio file, something like ffmpeg -i audio.ogg --start=5s --end-10s cut.ogg? [08:18:39 CEST] <c_14> rk[ghost]: https://trac.ffmpeg.org/wiki/Seeking [08:20:35 CEST] <grublet> "-ss is now also "frame-accurate" even when used as an input option. " [08:20:44 CEST] <grublet> too bad this wasnt a feature when i used ffmpeg more [08:35:08 CEST] <rk[ghost]> c_14: thanks [08:35:12 CEST] <rk[ghost]> grublet: too to know! [09:51:11 CEST] <darshan> HI [09:51:50 CEST] <darshan> i want to make slideshow with the jpg and png images and audio files but getting issue with concat commands [09:51:57 CEST] <darshan> can anyone help me [10:53:49 CEST] <Nacht> Goodmorning all [10:59:21 CEST] <Nacht> What command do you need to get ffmpeg to create a HLS VOD with .aac segments ? Mine keeps making .ts files [11:02:55 CEST] <ritsuka> Nacht: I think HSL requires either ts or fragmented mp4 [11:04:12 CEST] <JEEB> it can be raw audio as well [11:08:54 CEST] <Nacht> Tried using -f segments but that didnt work either [11:12:05 CEST] <gwohl> i thought HLS only makes .ts segments out of AAC sources [11:12:32 CEST] <gwohl> can't use AAC in the raw like that, you need a transport stream [11:12:57 CEST] <Nacht> It uses ADTS, so it should work. Apple has an example stream: [11:12:58 CEST] <Nacht> https://tungsten.aaplimg.com/VOD/bipbop_adv_example_v2/a1/prog_index.m3u8 [11:13:37 CEST] <ritsuka> yup the specs says "or a Packed Audio file, which is a file containing packed encoded audio samples and ID3 tags, such as AAC with ADTS framing [ISO_13818_7], MP3 [ISO_13818_3], AC-3 [AC_3], or Enhanced AC-3 [AC_3]. Transport of other media file formats is not defined." [11:13:39 CEST] <JEEB> gwohl: look at the HLS spec [11:13:50 CEST] <JEEB> it's a semi-idiotic thing but they actually allow raw audio streams [11:14:15 CEST] <Nacht> Yeah I suprised me as well when I read it at first [11:14:18 CEST] <JEEB> oh, fun it's up to revision 23 [11:14:19 CEST] <JEEB> https://tools.ietf.org/html/draft-pantos-http-live-streaming-23 [11:17:05 CEST] <darshan> hello i try with -f but does not work [11:17:18 CEST] <darshan> @Nacht [11:18:55 CEST] <Nacht> Tried -segment_list and naming them .aac. Tried -f segment with -segment_format aac. Didn't do it either. I wouldnt be suprised if ffmpeg doesnt have it tho [11:20:10 CEST] <JEEB> yea, libavformat will most likely not let you do it [11:20:26 CEST] <utopiah_> ffmpeg -i input.mp4 -vf scale=1024:512 -t 30 output.mp4 works (I have the right output file) but scale=2048:1024 or even scale=iw*.5:ih*.5 (since original is 4096:2048) doesn't... does the scale filter have a maximum resolution? [11:20:34 CEST] <JEEB> because generally you don't want streams without a container. if you are afraid of overhead you'd implement ISOBMFF fragments in HLS [11:21:12 CEST] <Nacht> Yeah I recon we're better off using an MPEGTS container [11:22:13 CEST] <Nacht> @utopiah_: which codec are you using ? [11:23:49 CEST] <utopiah_> h264/aac [11:25:18 CEST] <Nacht> Which profile ? [11:26:07 CEST] <Nacht> Cause you need a minimum of 5 using those resolutions. Also, it might be better using HEVC for those. [11:27:03 CEST] <Nacht> Oh wait, I misread, 4.0 does '2048x1024(a)30.0' [11:27:33 CEST] <utopiah_> https://gist.github.com/Utopiah/5ba53670160539a5ffe5a004bb9b0006#file-equir… [11:28:49 CEST] <utopiah_> scale to 1024:512 and 512:256 worked [11:33:05 CEST] <Nacht> When it doesn't work, does it given an error, or just gives out an incorrect size or corrupt file ? [11:42:05 CEST] <utopiah_> I dont get any error or warning, just a very small file ~200k that doesn't play [11:42:21 CEST] <Nacht> what does ffmpeg say about the ouput ? [11:43:22 CEST] <utopiah_> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5da4445800] moov atom not found [11:43:24 CEST] <utopiah_> Silence_high.mp4: Invalid data found when processing input [11:43:38 CEST] <utopiah_> file Silence_high.mp4 [11:43:41 CEST] <utopiah_> Silence_high.mp4: ISO Media, MP4 Base Media v1 [IS0 14496-12:2003] [11:44:53 CEST] <furq> pastebin the full encoding command and output [11:50:26 CEST] <utopiah_> http://vatelier.net/MyDemo/vrt/assets/log.txt [11:50:44 CEST] <utopiah_> input and output files are in the directory [11:51:38 CEST] <utopiah_> like I said in lower res it works so without error I dont get why higher res fails silently [11:52:47 CEST] <furq> er [11:52:52 CEST] <furq> frahm_high.mp4 plays back fine for me [11:54:06 CEST] <utopiah_> :| here too, wait a second [11:56:25 CEST] <utopiah_> I dont get it, maybe was the browser caching [11:56:29 CEST] <utopiah_> well, sorry about that [11:56:49 CEST] <furq> well silence_high.mp4 is broken [11:57:00 CEST] <furq> but i can't really debug that without a log [11:59:11 CEST] <utopiah_> trying a longer part then will try Silence agaf 1minin, [12:00:03 CEST] <utopiah_> seems a longer part fails again, could it be a memory limitation? [12:00:57 CEST] <furq> you'd probably notice if you were getting oom killed [12:01:07 CEST] <furq> that would cause the moov atom to not be written though [12:02:12 CEST] <utopiah_> checking https://trac.ffmpeg.org/ticket/596 yep probably that... not supposed to be in a VM though but will investigate [12:03:37 CEST] <furq> the oom killer logs to the syslog or kern.log [12:03:48 CEST] <furq> so if you're not getting a "Killed" message then you can check there to see if it's getting oom killed [12:04:45 CEST] <utopiah_> yes I just did when I redirected the log [12:05:24 CEST] <utopiah_> well it's just a test so for now I'll stick to a 20sec section, should do, thank you [12:06:26 CEST] <utopiah_> in fact Im doing it on a remote server, will probably just do it on my machine [12:07:04 CEST] <furq> you could maybe use a faster preset [12:07:05 CEST] <utopiah_> sorry for the noise, learning process ;) [12:07:25 CEST] <furq> faster presets will generally use less memory [12:07:33 CEST] <furq> or you could just lower rc-lookahead directly [12:39:17 CEST] <Fyr> guys, fmpeg -hwaccels shows cuvid and vaapi, while the computer has 0 NVidia cards and doesn't have Intel drivers pre-installed. [12:39:26 CEST] <Fyr> however, cuvid works. [12:39:34 CEST] <Fyr> is it a dummy? [12:43:32 CEST] <Fyr> do you happen to know a Linux distro with ffmpeg's hwaccels working? [12:47:32 CEST] <Fyr> so far I know, it requires Linux kernel recompilation to turn them on. [12:48:22 CEST] <Fyr> I failed to install even Intel's openCL drivers; it looks like my Ubuntu kernel is not generic. [12:50:24 CEST] <utopiah_> (OK definitely doing it on my local machine and not on the server ;) [12:51:34 CEST] <jkqxz> Fyr: What hwaccels do you want? Debian/Ubuntu stuff is compiled with at least VDPAU and VAAPI, I think. [12:51:49 CEST] <k_sze[work]> I need help switching from avcodec_encode_video2 to avcodec_send_frame/avcodec_receive_packet [12:52:02 CEST] <Fyr> jkqxz, any hwaccel available for Intel CPU. [12:52:07 CEST] <Fyr> QSV, I guess [12:52:07 CEST] <DHE> k_sze[work]: be specific [12:52:17 CEST] <k_sze[work]> Mainly, I don't understand how ref counting works when I use the new API. [12:53:01 CEST] <jkqxz> Fyr: VAAPI, then? (Unless you want to recompile your kernel and install all of the proprietary stuff to make libmfx work.) [12:53:10 CEST] <k_sze[work]> DHE: am I supposed to unref the AVFrame as soon as I have called avcodec_send_frame? [12:53:28 CEST] <Fyr> jkqxz, does VAAPI mean hardware decode? [12:53:54 CEST] <k_sze[work]> DHE: because logically, I have already sent the AVFrame into the codec pipeline, and my application doesn't need the AVFrame anymore. [12:54:15 CEST] <k_sze[work]> DHE: I suppose the codec takes a ref of the AVFrame when I call avcodec_send_frame? [12:54:31 CEST] <jkqxz> Yes. On Intel, VAAPI uses the same Quick Sync hardware as the proprietary QSV/libmfx stuff does. [12:54:50 CEST] <DHE> k_sze[work]: avcodec_send_frame says ownership remains with the caller. so yes, you need to unref it or free it entirely [12:55:49 CEST] <k_sze[work]> DHE: Is it safe to call av_frame_free on the AVFrame right after avcodec_send_frame? [12:56:00 CEST] <DHE> I just said yes [12:56:37 CEST] <k_sze[work]> You said "unref it or free it entirely", so if I don't call av_frame_free, what other function would I call to unref it only? [13:03:15 CEST] <k_sze[work]> And I suppose that I won't need to call av_init_packet because avcodec_receive_packet will be responsible for allocating a refcounted packet? [13:03:45 CEST] <k_sze[work]> which means I need to unref or free the packet after I have muxed it with av_interleaved_write_frame? [13:05:52 CEST] <k_sze[work]> Hmm, the doc says that Libavformat will always take care of freeing the packet, even if [av_interleaved_write_frame] fails. [13:23:47 CEST] <k_sze[work]> And next, AVCodecContext.coder_type and AVCodecContext.context_model are deprecated. [13:24:10 CEST] <k_sze[work]> I'm supposed to set encoder private options instead, but what are the new names of the private options? [13:24:20 CEST] <k_sze[work]> It's not mentioned in avcodec.h [13:28:20 CEST] <k_sze[work]> This? libavcodec/options_table.h:329:{"coder", NULL, OFFSET(coder_type), AV_OPT_TYPE_INT, {.i64 = DEFAULT }, INT_MIN, INT_MAX, V|E, "coder"}, [13:28:42 CEST] <k_sze[work]> (So it's named "coder" instead of "coder_type")? [13:41:24 CEST] <roasted> I'm trying to script a jpg snapshot capture of an IP camera via ffmpeg. If I run "ffmpeg -i rtsp://ip.to.camera/path/to/camera -vframems 1 pic1.jpg", it works, but I get a 461 transport error. Curious on what that may be, despite still obtaining the jpg successfully? [13:41:44 CEST] <roasted> -vframes* [14:39:49 CEST] <Nacht> I'm testing out with -vframes 1 to get a screenshot from a current ts file. However, I'd like to take 4 screenshots at 4 different times (0 sec, 2 sec, 4 sec and 6sec). Is it possible doing this faster then just with -ss ? As I notice that the 6 sec screen takes allot longer due to the seeking [15:46:25 CEST] <zack_s_> kepstin: I have a video which I need to cut without re-encoding, I use following cmd line: ffmpeg -ss 00:00:09.000 -i input.mp4 -vcodec copy -acodec copy -t 00:00:15.000 output.mp4 [15:46:48 CEST] <zack_s_> however, the cutted video ist 16 seconds long, altought I have every 30 FPS a key frame [15:46:53 CEST] <zack_s_> the video ist 30FPS [16:13:07 CEST] <styler2go> In general, does it take longer to compress a video or to save a video file uncompressed? [16:16:47 CEST] <Fyr> to compress, of course [16:19:18 CEST] <furq> depends how slow your disk is [16:26:44 CEST] <Fyr> >> In general [16:27:54 CEST] <kepstin> zack_s_: in most video formats, you can put the end point of a cut not on a keyframe... [16:28:02 CEST] <kepstin> it's only the start point that has to be on one [16:28:57 CEST] <zack_s_> kepstin: okay? how can ffmpeg do automaticall adjust the cut marks? [16:29:09 CEST] <zack_s_> automatically adjust the cut marks [16:29:20 CEST] <zack_s_> what do I have to do in order to get it working? [16:29:40 CEST] <kepstin> zack_s_: what do you mean? it's doing what you asked it to do, give a video section approximately 15 seconds long starting at as close to 9 seconds in as possible [16:30:35 CEST] <zack_s_> kepstin: ahhh wait [16:30:41 CEST] <zack_s_> the last parameter is the duration? [16:30:49 CEST] <kepstin> -t is duration, yes [16:30:52 CEST] <zack_s_> the absolute end time [16:30:55 CEST] <zack_s_> ahhhh [16:30:58 CEST] <zack_s_> that was my problem [16:48:55 CEST] <Pandela> Aye, so I have an image sequence of about 8000+ frames but the result is slightly longer and doesn't match the original videos audio length [16:49:17 CEST] <Pandela> Is there a way to sync the video length to match audio? [17:08:02 CEST] <furq> if the source is cfr then it should just work [17:10:26 CEST] <zack_s_> kepstin: I got some frame freezes at cut marks [17:10:40 CEST] <zack_s_> is this normal? [17:18:49 CEST] <kepstin> not sure what you mean by frame freezes, but I wouldn't be surprised if there's some weirdness at the end of cuts due to b-frames [17:20:15 CEST] <kazuma_> won't it cut to the nearest i-frame and not cut on b or p frames [17:21:03 CEST] <kepstin> the *start* of the cut will be on an I frame with -c:v copy, but the end won't necessarily be. [17:22:08 CEST] <Nacht> IDR frame [17:23:07 CEST] <furq> i've noticed weird behaviour around start points with -ss/-t [17:23:16 CEST] <furq> i think it's to do with audio [17:23:49 CEST] <furq> if i cut five seconds before a keyframe, it'll just show the first video frame for five seconds while the audio plays [17:23:53 CEST] <furq> at least with some formats it does that [17:24:58 CEST] <Nacht> That's cause you don't have an I frame, so it doesnt really show much till the first i frame it meets [17:25:21 CEST] <Nacht> Altho, IDR should be the better term here [17:26:39 CEST] <kepstin> hmm, that kinda makes sense given how most audio formats let you cut between any frames (module preroll that some codecs require) [17:30:06 CEST] <furq> yeah [17:30:22 CEST] <furq> it does make cutting more complicated though [17:31:22 CEST] <furq> i guess it makes sense that it goes by the stream which it can cut at the point you requested [17:31:27 CEST] <furq> it'd be nice if you could specify though [17:33:01 CEST] <zerodefect> When decoding, it safe to call av_read_frame in parallel with av_send_packet()/av_receive_frame() ? [17:40:36 CEST] <DHE> yes. the codec and format/container workers have no relation to each other [17:44:36 CEST] <zack_s_> kepstin: can I not specify the exact iframe to iframe cut marks, so that there are now issues at all? [17:45:28 CEST] <kepstin> zack_s_: there's probably always gonna be some misalignment from audio vs video, but you should be able to get it down to ~10ms difference on average with most codecs. [17:45:30 CEST] <zerodefect> Thanks DHE [17:46:12 CEST] <kepstin> zack_s_: no way to do that automatically, you're gonna have to use e.g. the ffprobe -show_frames output to figure out where you want to cut, I guess :/ [17:46:49 CEST] <kepstin> if it's CFR video and you know it has a fixed gop size you could just calculate the times I guess [17:48:07 CEST] <DHE> zerodefect: if the AVWhateverContext* being passed in thread A is unrelated to the AVSomethingContext* being passed in thread B, it's almost always safe to do so [17:48:21 CEST] <zack_s_> kepstin: yeah, I mean this [17:48:31 CEST] <zack_s_> with fprobe calculate [17:48:39 CEST] <DHE> since AVFormatContext and AVCodecContext are not related, have fun [17:48:52 CEST] <zack_s_> what is CFR video? [17:49:35 CEST] <DHE> constant framerate [17:51:30 CEST] <zack_s_> can I use fprobe to get me the next I frame form a certain position? [17:51:45 CEST] <zerodefect> Thanks DHE. This will be an interesting task. :) [17:52:21 CEST] <kepstin> zack_s_: with -show_frames, it prints out per-frame info including the frame type and timestamps, so you could figure it out from that. I dunno if there's a faster way to do it, maybe someone here is an ffprobe expert? :) [17:53:17 CEST] <DHE> zerodefect: you should see my app... [17:54:22 CEST] <zerodefect> Was it worth doing? Was there a noticeable performance improvement using parallel processing? [17:54:54 CEST] <zerodefect> I suppose it's difficult to quantify [17:56:15 CEST] <DHE> I needed it because I'm doing multiple encodes on the same content in real-time. threading was mandatory. [17:56:56 CEST] <c_14> zack_s_: something like ffprobe -count_frames -show_entries frame=best_effort_timestamp_time,key_frame -select_streams v -v quiet -hide_banner -of flat $FILE | grep -E -A 100 '$TIME' | grep 'key_frame=1' -A 1 | head -n2 [17:57:22 CEST] <c_14> (It might be better and definitely more robust to output json and use a script to do this instead) [17:57:31 CEST] <zerodefect> DHE: So was your use case threading av_send_frame/av_receive_packet ? [17:57:44 CEST] <c_14> But that may or may not work as long as your input timestamp resolution isn't too exact [17:57:55 CEST] <zack_s_> c_14: what does this give me? [17:58:16 CEST] <c_14> the next I-frame after a certain timestamp [18:00:43 CEST] <zack_s_> c_14: seems not to work [18:00:54 CEST] <zack_s_> I get no output at all [18:01:17 CEST] <zack_s_> ./ffprobe -count_frames -show_entries frame=best_effort_timestamp_time,key_frame -select_streams v -v quiet -hide_banner -of flat "1920x1080_30fps_2min.mp4" | grep -E -A 100 '00:00:08.123' | grep 'key_frame=1' -A 1 | head -n2 [18:01:29 CEST] <c_14> the timestamp is in seconds [18:01:45 CEST] <c_14> try just 8 [18:02:07 CEST] <c_14> 8.1 should probably work as well [18:02:21 CEST] <zack_s_> nothing [18:02:27 CEST] <zack_s_> but no really fast nothing [18:02:27 CEST] <zack_s_> :D [18:02:44 CEST] <c_14> try getting rid of the greps and checking the output manually [18:02:47 CEST] <Threads> windows or linux ? [18:02:50 CEST] <c_14> Like I said, this isn't a very robust solution [18:02:51 CEST] <zack_s_> windows [18:02:56 CEST] <c_14> oh [18:02:58 CEST] <c_14> well [18:03:00 CEST] <c_14> that won't work then [18:03:09 CEST] <zack_s_> I have a bash [18:03:14 CEST] <c_14> ah, then it might [18:03:28 CEST] <c_14> try getting rid of all the greps I guess [18:04:14 CEST] <zack_s_> ./ffprobe -count_frames -show_entries frame=best_effort_timestamp_time,key_frame -select_streams v -v quiet -hide_banner -of flat "1920x1080_30fps_2min.mp4" [18:04:17 CEST] <zack_s_> you mean this? [18:04:23 CEST] <zack_s_> no output at all [18:04:44 CEST] <c_14> get rid of -v quiet [18:09:18 CEST] <zack_s_> okay, this works [18:59:57 CEST] <FishPencil> What is the "sane range" for x265? CRF 18 is considered "visually lossless" for x264, what is it for x265? [19:47:29 CEST] <kepstin> nobody really knows, as far as I can tell? The scale has changed between x265 versions, too, at least for 10bit (apparently) [19:48:47 CEST] <kerio> does x265 support actual lossless [19:55:19 CEST] <furq> well the default crf for x265 is 28 [19:55:29 CEST] <furq> so probably just add 5 to what you'd use with x264 and hope for the best [19:56:04 CEST] <furq> https://pbs.twimg.com/media/CnqQ4PTWEAQXZDC.jpg [19:56:06 CEST] <furq> looking good kerio [19:56:50 CEST] <kerio> furq: https://media.giphy.com/media/DpN771RFKeUp2/giphy.gif [19:57:14 CEST] <furq> that is an extremely assange dance [19:59:00 CEST] <kepstin> kerio: yes, you can use it with ffmpeg by using '-x265-params lossless=1' iirc [19:59:26 CEST] <kerio> not -crf 0? :( [20:07:58 CEST] <kepstin> "-crf 0" isn't lossless on 10bit x264 either [20:08:16 CEST] <kepstin> on x264, the recommended way to request lossless is "-qp 0" [20:13:16 CEST] <FishPencil> How do you pipe to ffmpeg without quality loss? ffmpeg -i in.mp4 -c:v libx265 - | ffmpeg -i - -vframes 1 out.png [20:14:06 CEST] <kepstin> FishPencil: I'm not sure what you're trying to do there, that example should obviously be done in a single command without any pipes [20:14:48 CEST] <FishPencil> kepstin: I want to export a single frame that was encoded with x265 to a png [20:15:03 CEST] <kepstin> but in general - to avoid quality loss, don't re-encode. So either use -c copy, or decode to a raw format, or transcode to a lossless format. [20:15:40 CEST] <kepstin> FishPencil: to grab a single frame from a video, just do "ffmpeg -i in.mp4 -vframes 1 out.png" ... [20:15:55 CEST] <FishPencil> kepstin: I want it to be compressed with x265 first [20:16:08 CEST] <FishPencil> kepstin: This is for a quality compare [20:16:29 CEST] <kepstin> well, recompressing any video with a lossy codec will cause quality loss, and that has nothing to do with the pipe [20:17:23 CEST] <kepstin> i mean, you could pick different x265 settings to change the amount of quality loss (or even do lossless), but if you did that, there'd be no point in doing the transcode before grabbing the png... [20:18:39 CEST] <FishPencil> I'm trying to compare CRF vales in x265. The -crf option will be added but is not shown. I'd like to avoid encoding the entire input media to save a single frame for comparison sake [20:19:33 CEST] <FishPencil> ffmpeg -i in.mp4 -ss 00:01:00 -c:v libx265 -crf 18 -vframes out.png [20:19:38 CEST] <FishPencil> Something logically like that [20:20:15 CEST] <kepstin> FishPencil: ah, in that case, yeah, piping to a second ffmpeg to to the transcode to png makes sense. you can't do 2 encodes on the same video in one ffmpeg command [20:20:16 CEST] <FishPencil> -vframes 1* [20:20:31 CEST] <kerio> FishPencil: wouldn't what you literally just said work [20:20:39 CEST] <kepstin> FishPencil: your original command should be basically ok [20:20:47 CEST] <kerio> well you need a -f mp4 or something [20:21:03 CEST] <kepstin> mp4 can't be streamed, do matroska or mpegts or something [20:21:09 CEST] <kerio> nut :3 [20:23:44 CEST] <FishPencil> -ss 00:01:00 -c:v libx265 -crf 30 -f matroska - | ffmpeg -i - -vframes 1 seems to work, though I'm getting 'av_interleaved_write_frame(): Invalid argument' and 'Error writing trailer of pipe:: Invalid argument' [20:23:55 CEST] <kerio> FishPencil: also note that you'd only get keyframes this way [20:24:34 CEST] <FishPencil> kerio: Wouldn't that still be representative of a target CRF? [20:24:43 CEST] <kerio> sure [20:25:50 CEST] <kepstin> sure, but it wouldn't be representative of a whole video encoded with the codec, depending on psy motion optimizations, bitrate allocation between frame types, etc. [20:26:42 CEST] <FishPencil> Is there a better way to compare? [20:30:10 CEST] <kepstin> it's kind of funny, because e.g. x264 has a bunch of tunes that tweak its setting to give advantages in different artificial image quality tests. [20:30:20 CEST] <kepstin> e.g. "-tune psnr" or "-tune ssim" optimizes for specific visual quality metrics (by turning off its psychovisual optimizations), and "-tune stillimage" preserves noticable details that wouldn't be seen on an image in motion. [20:31:04 CEST] <kepstin> but a general video, in motion, will generally look best with none of those tunes enabled. [20:33:21 CEST] <FishPencil> So is there a better way to compare? [20:41:04 CEST] <kepstin> i dunno. THe 'vmaf' stuff by Netflix https://github.com/Netflix/vmaf doesn't seem /entirely/ terrible. [20:41:42 CEST] <kepstin> and for reasonably short clips, double-blind testing? [20:43:55 CEST] <FishPencil> I'm not sure why you couldn't just compare a still keyframe from the source to an encoded one [20:44:20 CEST] <furq> because that only tells you how well keyframes are compressed [20:44:54 CEST] <FishPencil> which is fine if you're just trying to find a crf value that appears visually lossless [20:49:25 CEST] <kepstin> for a keyframe only video, sure ;), and it'll probably give you a value that's higher quality than you need because of details that you'd only notice in still images. [20:49:51 CEST] <kepstin> then again, it's kinda hard to tell [20:50:45 CEST] <kepstin> If I was doing this, I'd encode some short video segments (20-30s?) in different formats, retranscode to the same lossless format for all of them, then do double-blind comparisons of the motion clips. [20:50:51 CEST] <kepstin> probably the best you could do? :/ [20:50:59 CEST] <kepstin> labour-intensive tho [21:28:42 CEST] <FishPencil> I'm surprised there isn't an easier way. The point of doing stills is so you can look back and forth between the two to look for details. That's pretty hard with a moving image. [21:29:39 CEST] <furq> is this something you'd expect video codec developers to optimise for [21:30:05 CEST] <kerio> i'd expect video codec developers to optimize for benchmarks ye :3 [21:30:07 CEST] <FishPencil> I suppose you could crop half of the video horizontal wise and the same for the encoded, then put them next to each other [21:31:21 CEST] <FishPencil> Then once the line between them becomes hard to notice you know you've hit a good point [21:32:21 CEST] <FishPencil> Is ffv1 a decent lossless video codec in FFmpeg? [21:32:25 CEST] <furq> yes [21:32:39 CEST] <FishPencil> As in well suited for this test? [21:33:37 CEST] <furq> as in a decent lossless video codec [21:33:45 CEST] <furq> anything would be well suited for this test [21:33:54 CEST] <furq> you haven't told us what other constraints you have [21:33:55 CEST] <kerio> ffvhuff is much much much much much much MUCH faster [21:34:13 CEST] <furq> yes and it also compresses (much){8} less well [21:34:24 CEST] <FishPencil> furq: There are none? Storage and processing power aren't an issue [21:34:25 CEST] <furq> missing a space there but never mind [21:34:40 CEST] <furq> well those are contrasting concerns [21:34:47 CEST] <furq> if you care about speed use ffvhuff, if you care about size use ffv1 [21:34:58 CEST] <furq> if you care about compatibility then don't use either [21:35:19 CEST] <FishPencil> I don't care about either, I'm simply going to go to lossless for a comparison [21:36:17 CEST] <furq> well you have to care about one more than the other or you'll never be able to choose [21:36:33 CEST] <FishPencil> I'll use ffv1 lol [21:45:47 CEST] <kerio> isn't ffv1 a standard [21:45:59 CEST] <kerio> an open standard used by library of congress and stuff like that [21:47:47 CEST] <furq> yeah but there's no vfw/dshow codec for it so it won't work in a lot of windows nles [21:47:54 CEST] <furq> and i don't think there's a quicktime codec either so you're fucked on osx as well [21:48:16 CEST] <furq> also idk if it's actually a standard yet [21:49:07 CEST] <furq> there's an ietf standardisation effort in progress [21:49:28 CEST] <furq> In 2015, the International Federation of Television Archives (FIAT/IFTA) mentioned FFV1 explicitly in their call-for-presentations for their annual World Conference, asking "Is FFV1 the new JPEG2000?" [21:49:32 CEST] <furq> lol fuck [21:49:34 CEST] <FishPencil> Is it possible to do this in one command? Encode the source to x265, crop it and pass it to a 2nd ffmpeg though a pipe, which takes the x265 encode and combines it with the source in another crop to save the output as ffv1? [21:50:02 CEST] <furq> yeah [21:51:20 CEST] <furq> ffmpeg -i foo.mp4 -c:v libx265 -vf crop=123:456 -f nut - | ffmpeg -i - -i foo.mp4 -filter_complex "[1:v]crop=789:012[tmp];[0:v][tmp]hstack" -c:v ffv1 out.nut [21:52:21 CEST] <FishPencil> I was real close to that [21:52:43 CEST] <kerio> >when you nut but she keeps encoding [21:53:19 CEST] <furq> no [21:53:39 CEST] <kerio> k :( [21:56:52 CEST] <zerodefect> DHE: Are you about? Do you have experience using 'FF_THREAD_FRAME' or 'FF_THREAD_SLICE' in combination with a custom 'execute' function? I've written some sample code to try it out, but I can't get the library to call my custom execute fn. [21:57:14 CEST] <zerodefect> Should mention that I'm talking about encoding :) [22:00:26 CEST] <FishPencil> Is there a way to seek and limit the duration of the in.mov in the pipe ffmpeg? ffmpeg -i in.mov -map 0:v -ss 00:01:00 -t 10 -vf "crop=1/2*iw:ih:0:0" -c:v libx265 -crf 20 -f matroska - | ffmpeg -i - -i in.mov -ss 00:01:00 -t 10 -filter_complex "[1:v]crop=1/2*iw:ih:1/2*iw:0[tmp];[0:v][tmp]hstack" -c:v ffv1 out.mkv [22:04:45 CEST] <FishPencil> Or does the cutting need to happen before? [22:05:26 CEST] <furq> that should work [22:05:35 CEST] <furq> oh nvm i'm looking at the wrong side [22:06:17 CEST] <furq> you'd need to use -ss and -t as input options before in.mov [22:06:34 CEST] <furq> certainly -ss anyway [22:06:40 CEST] <furq> it doesn't really matter with -t [22:06:42 CEST] <FishPencil> I'll just cut them before, [22:06:50 CEST] <furq> yeah that'll be quicker anyway [22:06:54 CEST] <furq> especially if you're doing this a lot [22:06:56 CEST] <atomnuker> zerodefect: just set the callback, that's all that's needed [22:07:04 CEST] <atomnuker> and the thread mode [22:07:27 CEST] <zerodefect> atomnuker: Can i show you some sample code via PasteBin? [22:10:22 CEST] <FishPencil> Amazing that FFmpeg can do this [22:14:30 CEST] <FishPencil> It looks great btw, can we agree that this is a proper comparison? [22:21:15 CEST] <cableguy> hey team [22:21:24 CEST] <cableguy> im using -ss and -t to split .vob file [22:21:30 CEST] <cableguy> but it looks like its reencoding the audio [22:21:38 CEST] <cableguy> how do i split the vob untouched with no reencode? [22:22:08 CEST] <FishPencil> cableguy: You mean just the video? [22:23:25 CEST] <relaxed> cableguy: -map 0 -c copy [22:24:15 CEST] <furq> are you splitting it by title/pgc [22:24:27 CEST] <furq> because you probably shouldn't use ffmpeg for that [22:26:49 CEST] <cableguy> ur probably right [22:26:56 CEST] <cableguy> but i cant find any command line on windows [22:27:00 CEST] <cableguy> can you recommend any [22:27:28 CEST] <furq> use pgcdemux on windows [22:27:40 CEST] <cableguy> is it cli [22:27:44 CEST] <furq> it has a cli [22:27:46 CEST] <cableguy> im sure i had it and it was gui [22:28:02 CEST] <cableguy> funny i found mkvmerge actually splits vob to vob but it adds its matroska headers [22:28:06 CEST] <furq> it's a pain in the arse to use but it'll at least be accurate [22:28:27 CEST] <furq> i generally just used the gui instead [22:28:28 CEST] <madprops> hi, I have an an mp4 with no sound and i have an aac audio file. I want to merge them but have the aac start after the first 4 seconds. Anyone knows how to do that? [22:28:41 CEST] <furq> -itsoffset [22:28:46 CEST] <furq> or reencode the audio and -af adelay [22:28:52 CEST] <cableguy> is the pgcdemux.exe same one file for gui and cli [22:28:55 CEST] <furq> yeah [22:29:20 CEST] <relaxed> with -itsoffset it will need to be in a container, like .m4a [22:29:45 CEST] <kepstin> well, yes, but you can't merge audio and video without putting it into a container... [22:29:58 CEST] <relaxed> no, I meant the audio input [22:30:43 CEST] <cableguy> whats the help switch for pgcdemux cli [22:30:47 CEST] <furq> -help [22:31:07 CEST] <cableguy> its not working [22:31:15 CEST] <cableguy> i get invalid input type and then it launches gui [22:31:27 CEST] <furq> https://www.videohelp.com/software/PgcDemux [22:31:30 CEST] <furq> you need that version [22:31:35 CEST] <furq> the MOD version [22:31:51 CEST] <madprops> furq, i tried this ffmpeg -i 2bil.mp4 -i audio1bil.aac -itsoffset 4.1 -c copy test.mp4 [22:31:56 CEST] <furq> also it shows the help text in a dialog box which is fucking stupid [22:32:05 CEST] <madprops> but it's wrong [22:32:12 CEST] <madprops> says im applying itsoffset to the output file [22:32:17 CEST] <furq> itsoffset is an input option [22:32:20 CEST] <furq> move it before -i [22:32:41 CEST] <relaxed> -itsoffset 4.1 need to be before the audio, and I believe you need to remux the aac file into .m4a first [22:34:15 CEST] <madprops> this made a video ffmpeg -i 2bil.mp4 -itsoffset 4.1 -i audio1bil.aac -c copy test.mp4 [22:34:21 CEST] <madprops> but without the audio [22:34:28 CEST] <madprops> relaxed, do i have to make it m4a then? [22:35:05 CEST] <cableguy> so is it -customvob with all the flags or -novob furq [22:35:43 CEST] <relaxed> do this, ffmpeg -i audio1bil.aac -c copy audio1bil.mka", then "ffmpeg -i 2bil.mp4 -itsoffset 4.1 -i audio1bil.mka -map 0 -map 1 -c copy test.mp4" [22:36:32 CEST] <furq> i've never really used the cli [22:36:46 CEST] <furq> i expect you want customvob though [22:36:55 CEST] <furq> i assume that creates a vob instead of demuxing the streams [22:38:04 CEST] <furq> afaik you want -vob -nom2v -noaud [22:38:17 CEST] <furq> or -m2v -aud -novob if you do want the streams demuxed [22:38:34 CEST] <madprops> relaxed, it merged them but it didn't delay the audio [22:39:51 CEST] <relaxed> try -itsoffset 00:00:04.1 [22:40:22 CEST] <madprops> maybe the decimal is wrong? [22:40:34 CEST] <madprops> i'll try that [22:41:16 CEST] <madprops> nope [22:41:21 CEST] <madprops> still no delay [22:42:34 CEST] <cableguy> furq, nothing is happening it doesnt do anyuthing, doesnt print any errors [22:43:10 CEST] <cableguy> wait up [22:43:15 CEST] <cableguy> input has to be .ifo [22:43:23 CEST] <cableguy> i cant just select a vob [22:43:27 CEST] <furq> yeah [22:44:38 CEST] <relaxed> madprops: works for me [22:44:40 CEST] <ChocolateArmpits> How should I test for freezes or hangs? I've had a livestream encode go for 7 days and then it just stopped with no messages. [22:45:15 CEST] <ChocolateArmpits> The memory usage was also good [22:45:46 CEST] <ChocolateArmpits> Excuse me, it didn't stop, it just froze [22:46:42 CEST] <kepstin> yeah, I can't get audio delay to work with itsoffset either, dunno what's up. I can delay video, but not audio (whether i'm copying or re-encoding) [22:46:43 CEST] <kepstin> hmm. [22:47:04 CEST] <ChocolateArmpits> kepstin, did you try using asetpts? [22:47:10 CEST] <relaxed> kepstin: is the audio in a container? [22:47:22 CEST] <kepstin> relaxed: either way same result [22:47:43 CEST] <kepstin> (i tried both standalone aac and acc-in-mp4) [22:48:53 CEST] <cableguy> furq, wait so how do you set duration or size when splitting vobs [22:49:50 CEST] <relaxed> kepstin: command? [22:49:51 CEST] <Threads> you still trying to get frameacurate cutting ? [22:50:04 CEST] <madprops> relaxed, weird hmm, thanks for the help [22:50:12 CEST] <furq> you don't [22:50:19 CEST] <furq> you select a pgc [22:50:28 CEST] <relaxed> I tested with aac in mp4 and that worked as well. [22:50:31 CEST] <furq> or vob id, or chapter, or angle, or whatever [22:50:52 CEST] <furq> if you just want to split at an arbitrary timestamp then use ffmpeg [22:51:00 CEST] <furq> i assumed you were splitting titles [22:51:19 CEST] <kepstin> relaxed: I'm using "ffmpeg -v debug -f lavfi -i testsrc -itsoffset 10 -i test.m4a -c copy -c:v libx264 -t 40 test.mp4" and the audio is not delayed by 12 relative to the video :/ [22:51:47 CEST] <relaxed> use video in a container [22:51:56 CEST] <kepstin> if I move the -itsoffset to in front of the video, then the video is correctly delayed by 10s [22:53:55 CEST] <kepstin> same result if I put the video in a container as a separate step. [22:56:10 CEST] <kepstin> there's been a longstanding ticket open for this, it looks like: https://trac.ffmpeg.org/ticket/1349 :/ [22:56:52 CEST] <FishPencil> furq: I noticed some artifacting on the edge if the x265 stream was cropped and compressed. This fixed it: [0:v]crop=iw/2:ih:iw/2:0[right];[1:v]crop=iw/2:ih:0:0[left];[left][right]hstack [22:57:21 CEST] <madprops> relaxed, "Unfortinately -itsoffset option works only for video streams. Do not use it for audio." [22:57:27 CEST] <cableguy> furq, so how you split without reencoding with ffmpeg, i select size or timestamps but it converts audio bitrate for no reason [22:57:36 CEST] <furq> -c copy [22:57:40 CEST] <relaxed> strange that it works for me [22:58:21 CEST] <madprops> he's probably wrong [22:58:26 CEST] <madprops> im reading about adelay now [22:59:00 CEST] <madprops> also there's this relaxed https://trac.ffmpeg.org/ticket/1349 [22:59:09 CEST] <relaxed> madprops: try -i audio1bil.mka -itsoffset -4.1 2bil.mp4 ... [22:59:50 CEST] <kepstin> I don't think putting a negative adjustment on the video works when muxing to mp4 :/ [23:01:10 CEST] <madprops> yeah that didn't work [23:01:32 CEST] <relaxed> it works with matroska [23:02:34 CEST] <relaxed> it's hacky, but then remux the matroksa to mp4 :) [23:03:57 CEST] <kepstin> hmm, not working for me muxing to mkv either, like ffmpeg -itsoffset -10 -i test.m4v -i test.m4a -c copy test.mkv [23:04:10 CEST] <kepstin> positive offset works there, of course. [23:04:28 CEST] <relaxed> no, put the audio before -itsoffset [23:04:57 CEST] <cableguy> furq, ffmpeg -i VTS_01_1.VOB -c copy -ss 00:00:00 -t 00:10:00 -target pal-dvd out1.VOB task manager shows 50% cpu so its reencoding something? [23:05:24 CEST] <furq> well yeah you're using -target [23:05:30 CEST] <furq> don't [23:05:33 CEST] <kepstin> relaxed: nope. "ffmpeg -i test.m4a -itsoffset -10 -i test.m4v -c copy test.mkv" they still both start at the same time :/ [23:05:45 CEST] <madprops> relaxed, i think the problem might be that the video has an audio track, though it's just silence [23:05:59 CEST] <kepstin> hmm, my test video doesn't have any audio track [23:06:08 CEST] <relaxed> kepstin: can you put your samples up somewhere? [23:06:09 CEST] <cableguy> hey ur right [23:06:43 CEST] <madprops> kepstin, hmm [23:07:26 CEST] <kepstin> relaxed: make them yourself: "ffmpeg -f lavfi -i testsrc -c:v libx264 -pix_fmt nv12 -t 30 test.m4v" and "ffmpeg -f lavfi -i sine -c:a aac -t 30 test.m4a" [23:07:38 CEST] <relaxed> madprops: after the last input add -map 0 -map 0:v [23:08:09 CEST] <madprops> oh wait a minute [23:08:13 CEST] <madprops> it's actually doing the opposite [23:08:25 CEST] <madprops> it's "removing" 4 seconds from the video file [23:09:03 CEST] <madprops> wait [23:09:28 CEST] <relaxed> switch your inputs [23:09:35 CEST] <kepstin> er, wait, why did I do 'm4v' there, that's raw mp4 video, not a container [23:09:37 CEST] Action: kepstin fixes that [23:10:50 CEST] <kepstin> hmm. no difference in the result [23:10:53 CEST] <relaxed> kepstin: this works for me, ffmpeg -i test.m4a -itsoffset -4 -i test.m4v -map 0 -map 1 -c copy -y out.mkv [23:11:49 CEST] <kepstin> relaxed: so when you play that file, you get 4s of video with silence, then the audio starts? (or alternately the video just starts with the number '10'?) [23:11:52 CEST] <relaxed> also works if I use mp4 as the output [23:11:54 CEST] <kepstin> er, 4 in your case [23:11:58 CEST] <relaxed> correct [23:12:26 CEST] <kepstin> ... so why does this work for you but not me [23:12:36 CEST] <kepstin> what ffmpeg version are you running? [23:12:50 CEST] <madprops> wait! [23:12:56 CEST] <relaxed> ffmpeg version N-86433-g81fc617c12 (git from a few days ago) [23:13:01 CEST] <madprops> this is weird, it actually worked if i inspect it with my video editor [23:13:08 CEST] <madprops> but the windows video player starts the audio imidiatelly [23:13:14 CEST] Action: kepstin tried 3.3.1 and 3.1.8, and is using mpv to test playback [23:13:23 CEST] <relaxed> hmm, I'm playing back with mpv if that matters [23:14:04 CEST] <relaxed> and it does matter :( ffplay doesn't respect the offset [23:14:31 CEST] <furq> kepstin: m4v is just mp4 [23:14:32 CEST] <kepstin> i wonder if the difference is our *mpv* versions, and our files are actually the same :/ [23:14:41 CEST] <kepstin> furq: no, see ffmpeg -h muxer=m4v ;) [23:14:59 CEST] <relaxed> mpv 0.25.0-131-g6489b112a [23:15:00 CEST] <furq> huh [23:15:19 CEST] <kepstin> huh, although I guess the 'm4v' extension must be attached to the 'mp4 muxer [23:15:28 CEST] <kepstin> the .m4v file I have is in fact an mp4/isombff file [23:15:33 CEST] <kepstin> that's confusing [23:15:49 CEST] <furq> i was about to say [23:15:55 CEST] <furq> .m4v uses the ipod muxer [23:16:05 CEST] <furq> which is correct as far as i'm concerned [23:16:22 CEST] <furq> every m4v i've ever seen in the wild has been a video from itunes [23:16:46 CEST] <madprops> mpv doesn't even reproduce the audio [23:17:32 CEST] <furq> what even is "raw mp4 video" [23:17:51 CEST] <furq> i assumed it would be length-prefixed h264, but the default encoder for it is mpeg4 [23:17:55 CEST] <kepstin> sorry, "raw mpeg 4 (asp) video" [23:17:56 CEST] <relaxed> mpeg4 elementary stream ? [23:18:22 CEST] <madprops> downloading vlc [23:18:43 CEST] <furq> i can mux h264 into m4v [23:19:30 CEST] <relaxed> right, Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test.m4v': [23:19:44 CEST] <furq> i mean with -f m4v [23:20:15 CEST] <kepstin> furq: yeah, weird, looks like it gives the same result as -f h264 [23:20:27 CEST] <furq> yeah i just noticed that [23:20:33 CEST] <furq> the encoder says "m4v" but then ffprobe says h264 [23:20:38 CEST] <furq> fuck knows [23:20:54 CEST] <furq> i'm glad .m4v uses ipod anyway [23:21:07 CEST] <furq> whatever -f m4v is doesn't seem in line with how that extension is used [23:21:26 CEST] <kepstin> both list the 'm4v' extension, so I guess it just depends on the order in the list of formats or something :/ [23:21:36 CEST] <madprops> no audio in vlc [23:21:44 CEST] <madprops> something's very wrong with my files [23:23:16 CEST] <madprops> here's the info of the merged file http://i.imgur.com/n7r1cqm.jpg [23:23:20 CEST] <FishPencil> Is there anything FFmpeg can do with gainy material? I feel like most of the bitrate is being used to reproduce the grain [23:23:28 CEST] <furq> use a denoiser [23:23:41 CEST] <furq> hqdn3d is reasonably good and fast [23:35:41 CEST] <madprops> btw i made it [23:35:58 CEST] <madprops> i removed the audio channel from the original video into an mkv and used that to merge [23:36:11 CEST] <madprops> the empty audio channel was messing things up [23:58:44 CEST] <FishPencil> If speed isn't an issue, is there a better denoiser than hqdn3d? [00:00:00 CEST] --- Fri Jun 16 2017

1 0