November 2018 - Ffmpeg-devel-irc

ffmpeg-devel.log.20181114
by burek 15 Nov '18

15 Nov '18

[00:20:15 CET] <akravchenko188> jkqxz: Hi, did you have a chance to review/test amf patches from November 2? [09:30:02 CET] <cone-716> ffmpeg 03Paul B Mahol 07master:759589b55ee5: avcodec/huffyuvenc: add support for gbrp16 [12:03:51 CET] <JEEB> durandal_1707: ok, I think I've got it. the initial sub2video fix that's in master now works, except it blocks the filter chain for quite a while. the one on the mailing list fixes that behavior, but instead it seems to lead to slowness XD [12:07:55 CET] <JEEB> I think I'll have to look into it a bit more later, but at this point I'm almost tempted to just note FU at sub2video's current incarnation [12:11:58 CET] <durandal_1707> sub2video is for bitmap subtitles? [12:34:02 CET] <JEEB> durandal_1707: yea [12:34:28 CET] <JEEB> I tried to document how it works with the patch on the ML [12:35:03 CET] <JEEB> that said it seems ot base a lot on stuff that used to be true/limited [13:48:29 CET] <abi> hi [14:06:34 CET] <cone-041> ffmpeg 03James Almer 07master:752659327d4a: avcodec/libdav1d: fix build after a recent API break [14:53:22 CET] <thardin> what would it take to get listed on the consulting section of the website? [14:56:05 CET] <jamrial> a patch, i guess [14:58:48 CET] <thardin> this is also reminding me that I have some mxfdec patches to develop [17:24:20 CET] <durandal_1707> who will update web page news for 4.1? [17:27:41 CET] <jamrial> it wasn't updated? [17:27:55 CET] <jamrial> huh. i'll do it then [19:26:47 CET] <JEEB> cool, I didn't even notice that the libdav1d wrapper got applied [19:39:48 CET] <nevcairiel> and a week later it broke [19:39:52 CET] <nevcairiel> a good sign that it was too early =p [19:47:04 CET] <cone-041> ffmpeg 03Jan Ekström 07master:b31a4be15f56: lavf/dashenc: set FLAC manifest codec string to "flac" [19:47:38 CET] <JEEB> I didn't even think anyone would use FLAC in MPEG-DASH, but there was at least one user to report it was broken in #ffmpeg [19:47:41 CET] <JEEB> lol [23:59:52 CET] <jamrial> jkqxz: guess you took it from cbs_vp9 [00:00:00 CET] --- Thu Nov 15 2018

1 0

ffmpeg.log.20181114
by burek 15 Nov '18

15 Nov '18

[00:00:57 CET] <JEEB> can't speak for everyone but if it's his own code and he has only used any leaked stuff for hints at how things work, then the result is still under his copyright. not as great as full RE of course :P [00:01:46 CET] <Pdrome> I don't come here to put project contribs noses out of joint or to cause trouble, I just don't feel confident starting to use FFmpeg with regards to a commercial game if RADs leaked code is in use then could 'FFmpeg using gamedevs' be liable? [00:02:41 CET] <JEEB> I don't know what hypothetical scenario we're talking about, nor about juristiction etc [00:02:46 CET] <Pdrome> I promise I will be back with link to the mailing list entry soon as i refind it [00:02:48 CET] <JEEB> nor am I a lawyer [00:03:40 CET] <JEEB> also for the record, you can disable complete functionality in FFmpeg if you don't like it or don't want to distribute binaries with that functionality in it [00:03:59 CET] <Pdrome> ^interesting thanks. [00:04:28 CET] <JEEB> quite a few people do it anyways since FFmpeg has so many minor/barely tested formats implemented [00:11:02 CET] <Pdrome> I should also state that rads source code is still up online after all these years - it is in one of the avp1 source code mirros [00:11:05 CET] <Pdrome> mirrors [00:13:02 CET] <JEEB> I would be surprised if that was the actual RAD codec code [00:13:32 CET] <JEEB> game developers generally don't need to get that far, they just need the headers etc to be able to use bink dlls [00:18:15 CET] <JEEB> also I didn't even notice Kostya had published a WIP patch for bink2 when he gave up [00:18:29 CET] <JEEB> you just caused me to go through his blog posts regarding bink [00:18:30 CET] <JEEB> lol [00:18:53 CET] <Pdrome> it is bink.c [00:19:08 CET] <Pdrome> the headers are also near the C file [00:19:56 CET] <JEEB> ok, don't worry then it seems :P that seems to be their wrapper around the bink interfaces :P [00:20:02 CET] <JEEB> stuff link BINK *binkHandle [00:20:03 CET] <Pdrome> I wonder if avp1 is where the leak that ffmpeg acquired originated from [00:20:56 CET] <JEEB> nope [00:21:05 CET] <JEEB> it literally uses bink's APIs to open a file and play it [00:21:17 CET] <Pdrome> also the DLLs are there as well and also bink_Rad.h [00:21:21 CET] <JEEB> looking at that bink.{c,h} and bink_Rad.h [00:21:42 CET] <JEEB> so MPC might have gotten the bink_Rad.h from something like this back in ye olden days [00:21:47 CET] <JEEB> but that only documents the interfaces [00:21:59 CET] <Pdrome> yeah avp1 was nearly 20yrs old now [00:22:19 CET] <JEEB> so what you would be able to do with this is just know how to take bink dll and play a video with it :P [00:22:25 CET] <Pdrome> and the later avp1 source code release has removed those radgame tools source code files [00:22:49 CET] <Pdrome> Thanks JEEB for the insight [00:22:57 CET] <JEEB> I hope the differencei s clear between these things :P [00:23:50 CET] <Pdrome> it isn't crystal clear (as I am new to gamedev) but it is simple enough for me to appreciate basic understanding given my gamedev research up to this point ;o) [00:26:49 CET] <Pdrome> I know other commercial developers have used FFmpeg in games but without knowing if in the clear or not, most could be unaware of the rad source code leak association to FFmpeg project [00:27:11 CET] <Pdrome> the more I just googled the more I think it was realting to RADs Bink Video [00:30:33 CET] <JEEB> basically, the stuff that avp dump has is 100% useless for FFmpeg [00:30:45 CET] <JEEB> since FFmpeg doesn't want to just use the bink DLLs [00:31:18 CET] <JEEB> also you may poke Kostya yourself if you want to ask some questions to him to be honest [00:31:26 CET] <JEEB> https://codecs.multimedia.cx/2009/07/brief-notes-about-bink/ is his blog [00:34:04 CET] <Pdrome> How would I poke him? [00:34:17 CET] <JEEB> e-mail or otherwise [00:34:44 CET] <JEEB> you can see his e-mail in his commits :P http://git.videolan.org/?p=ffmpeg.git;a=search;h=HEAD;s=Kostya+Shishkov;st=… [00:35:29 CET] <JEEB> originator of http://git.videolan.org/?p=ffmpeg.git;a=commit;h=342c7dfdbb46b1ff778ef142dc… [00:36:13 CET] <Pdrome> Oh nice, what is his link to FFmepg - eg is he the main developer or is he just best to ask as he worked on RE bink so much?# [00:36:26 CET] <JEEB> he is the author of the decoder :P [00:36:30 CET] <JEEB> he reverse engineered it [00:38:04 CET] <Pdrome> I will try to email him, thanks for all your help JEEB [00:45:28 CET] <JEEB> the only thing I find with any relevant keywords from GOOG is where a person mentions that he has access to the Real Video 4 spec, but that he is under an NDA and cannot share it from 2010's IRC logs [00:45:47 CET] <JEEB> which a) isn't Bink b) pretty clear that nothing was passed on [00:46:10 CET] <JEEB> so so far I can just see you making random allegations [00:46:26 CET] <JEEB> possibly out of not understanding what is discussed [00:48:47 CET] <Pdrome> thats is the thing, I don't want to alledge anything, I just want to understand what the situation is regarding what i found about RAD source on an old FFmpeg mailing list entry.. and until I can actually refind that specific mailing list entry, I dont really have any position to ask from [00:49:06 CET] <Pdrome> earlier above I said the allude as that was the best word i could think of [00:49:31 CET] <Pdrome> I dont want to alledge anything as even I am not sure what exactly the situation is [00:49:47 CET] <JEEB> given the history of kostya regarding random game formats getting done (obviously by means of RE/open research) I would also pretty much default to it being RE'd :P [00:49:54 CET] <Pdrome> you have helped JEEB fill in some things for me which is both interesting and helpful [00:50:21 CET] <Pdrome> I have now sent the email so at the very least Kostya will get a laugh out of my obvious ignorance ;o) [00:51:43 CET] <Pdrome> i am 100% sure the mailing list entry was regarding RAD software and not Real [02:22:07 CET] <JEEB> auri_: sent a patch for the FLAC MPEG-DASH identifier to the mailing list [02:25:55 CET] <ealdeguer> Hi FFMPEG Team, [02:25:56 CET] <ealdeguer> I attended Demux in SF, and Will Law(akamai) demoed CMAF low latency. [02:25:56 CET] <ealdeguer> I understood it was possible to package a source to HLS - CMAF with FFMPEG [02:25:57 CET] <ealdeguer> but I'm not sure how and can't find much on google, can you guys help ? [02:26:00 CET] <ealdeguer> I already managed to take a source, encode it with x264, package it as regular HLS with ffmpeg and push it to Akamai, but I wonder how it could work with CMAF ? [02:53:52 CET] <KombuchaKip> Hey everyone. I'd really appreciate a code review of my custom AVIOContext for reading media from memory: https://pastebin.com/NGALFw8Y [02:54:24 CET] <remlap> Hi I am trying to build ffmpeg but I get ERROR: chromaprint not found but I have it installed [03:02:23 CET] <relaxed> remlap: do you have libchromaprint-dev installed? [03:02:27 CET] <remlap> yes [03:02:42 CET] <relaxed> pastebin.com the end of ffmpeg's config.log [03:04:12 CET] <remlap> https://pastebin.com/ieZ28BvT this enough? [03:05:45 CET] <relaxed> /usr/bin/ld: warning: libcodec2.so.0.7, needed by //usr/local/lib/libavcodec.so.58, not found [03:06:57 CET] <remlap> libcodec2-dev install [03:07:34 CET] <remlap> libcodec2-0.8.1 install [03:07:46 CET] <remlap> 'ed [03:09:05 CET] <relaxed> that provides /usr/lib/x86_64-linux-gnu/libcodec2.so.0.8.1 [03:09:39 CET] <remlap> yes so to new? [03:10:35 CET] <relaxed> yes [03:11:05 CET] <remlap> how would I correct for that (noob sorry) [03:11:27 CET] <relaxed> you need libcodec2.so.0.7 installed [03:13:21 CET] <remlap> my os comes with libcodec2.so.0.8.1 so I am bit out of luck? [03:25:57 CET] <remlap> that's weird [03:25:59 CET] <remlap> its building now [03:26:35 CET] <remlap> configure went ok and now make is running, fingers crossed [04:06:16 CET] <PhantomOfNyx> there we go I'm not used to IRC, quick question in libx264, I've kinda succeded getting the quality for my stream i want but the high quality of getting rid of all grain and blurr results in another thing becoming more obvious .... color banding [04:07:46 CET] <PhantomOfNyx> I had truly not noticed until I cleaned out the blur but is there anyone in here with any smart ideas for reducing that or making it blend further, it's only in obvious stuff like areas with a lot of the same color ( loading screens or specifically torches lighting effect in minecraft becomes bad, mainly because it happens in game but it's just amplified 10x on after the encode) <3 [04:53:00 CET] <Hello71> did you turn off dithering [05:22:45 CET] <saucecode_> I'm using OBS to record gameplays, and I've set it up to record an audio streams for the game, and a stream for my microphone. So it outputs a file with a video stream and two audio streams. [05:23:28 CET] <saucecode_> Is there an easy way to merge the two audio streams from the same file into one stream, with copied video? [09:18:00 CET] <bencc> how can I convert mp3 file to mp4 with black video frames? [09:18:42 CET] <bencc> ffmpeg -i audio.mp3 -c:a aac -b:a 128k -vn out.m4a [09:19:05 CET] <bencc> this encode to m4a. now I'm trying to encode to mp4 with black video stream [09:27:41 CET] <furq> bencc: -i audio.mp3 -f lavfi -i color=black:s=1280x720 -shortest -c:a copy out.m4a [09:27:53 CET] <furq> or -c:a aac if you want aac [09:28:05 CET] <furq> no reason to do that unless you need to though [09:29:02 CET] <furq> also that should be out.mp4 although i don't remember how much difference it makes, if any [09:31:43 CET] <bencc> furq: thanks [09:31:46 CET] <bencc> no reason to do what? [09:31:53 CET] <furq> no reason to reencode the audio [09:32:03 CET] <furq> most stuff supports mp3 in mp4 [09:32:27 CET] <bencc> ok. I'll try without reencoding [09:32:53 CET] <bencc> I saw people do "-c:v libx264 -tune stillimage -pix_fmt yuv420p -shortest" [09:33:36 CET] <furq> you don't need either but they won't hurt [09:33:51 CET] <furq> i can't imagine stillimage will have any effect on a totally black frame [09:33:58 CET] <furq> and the color source defaults to yuv420p anyway [09:37:17 CET] <bencc> cool [09:38:28 CET] <ritsuka> apple doesn't support mp3 in mp4, so avoid it if you need to play it back on a mac or iphone [09:48:19 CET] <bencc> ritsuka: I do need safari. I'll avoid it [10:31:33 CET] <llanotheroom> hi, I developed a library based on libav*. It adds run time control when do video audio/video process, such as add new input/output streams, request I frame, etc.. I would like to seek your suggestions, also desired features not supported by current version of FFmpeg which I may give a try then. [10:31:45 CET] <llanotheroom> https://github.com/Xingtao/FFdynamic [13:49:14 CET] <abi> hi [14:24:08 CET] <th3_v0ice> Why would a packet coming from the UDP given by av_read_frame have AV_NOPTS_VALUE for PTS and DTS while having size and data != 0 ? [16:36:02 CET] <fahadash> What is wrong with this? ffmpeg -i .\PostmanInterceptor.webm -filter_complex "[0:v]trim=duration=13[a];[0:v]trim=start=40:duration=60,setpts=PTS-STARTPTS[b];concat=[a][b]" -y Postmaninterceptor.MOV [16:36:24 CET] <fahadash> I am getting this error [AVFilterGraph @ 03e1cbc0] No output pad can be associated to link label 'b'. [16:38:37 CET] <fahadash> Found it nvm [16:47:25 CET] <th3_v0ice> If I have an input video of 12288x5760 and want to have 1080p output without black bars, how can I do that? [16:48:11 CET] <kepstin> th3_v0ice: crop off the sides [16:49:27 CET] <th3_v0ice> How? One more question. The original is in yuva444p10le, specifying pix_fmt yuv420p removes alot of color from the output, is there a way to remedy this? [16:49:29 CET] <furq> or resize to 1920*900 [16:49:45 CET] <furq> that's still technically 1080p [16:49:52 CET] <th3_v0ice> I am more interested in 1080 height, [16:50:31 CET] <furq> going from 10-bit 4:4:4 to 8-bit 4:2:0 is specifically going to remove colour information [16:51:30 CET] <kepstin> th3_v0ice: 10-bit video like that might be HDR, you might have to tonemap it to make it look good [16:51:57 CET] <furq> i'm guessing from the input res that it's from a camera so yeah [16:52:48 CET] <th3_v0ice> Yeah, raw information from camerea. So there is no automatic option that tries to map the colors? [16:53:30 CET] <furq> there's a tonemap filter but i've never had cause to use it [16:53:33 CET] <furq> https://ffmpeg.org/ffmpeg-filters.html#tonemap-1 [16:55:33 CET] <furq> anyway to crop and scale it you want -vf "crop=ih*(16/9):ih:(iw-ow)/2:0,scale=1920:1080" [16:59:31 CET] <th3_v0ice> That did the trick for the video size, thanks! Let me try the tonemapping part. [17:01:51 CET] <th3_v0ice> Guess I am out of luck for that one :) code 3074: no path between colorspaces [17:11:34 CET] <JEEB> you can only convert video to float with zscale [17:11:36 CET] <JEEB> (and back) [19:49:49 CET] <JEEB> auri_: the patch is now in master [19:53:38 CET] <ChocolateArmpits> Is there any practical purpose to "initial_pause" rtsp parameter? [21:52:39 CET] <GuiToris> hey! can you help me with the presets of the x26[45]? I don't understand it. According to the ffmpeg guide they only affect the file size ( quote: The visual quality will be the same) Well I compared ultrafast and veryslow, and ffmpeg guide cannot be true. There are huge differencies between ultrafast and veryslow. [21:53:02 CET] <GuiToris> So I don't know, does it really improve the quality? [21:53:36 CET] <GuiToris> or they are just filters and they look nicer [21:54:01 CET] <JEEB> for the same file size if the only difference is the preset, the slower ones will look better of course [21:54:26 CET] <JEEB> since with each slower preset you enable features and use more CPU time to try and compress the video better [21:55:10 CET] <GuiToris> JEEB: should I use a slower preset or a higher crf number to achieve better quality? [21:55:39 CET] <GuiToris> JEEB: hey, no the file sizes were different [21:55:42 CET] <JEEB> both. you use the slowest preset that is still fast enough for you, and then you tweak the CRF value to your needs [21:56:11 CET] <JEEB> because the results of the CRF value depend on the preset [21:56:25 CET] <GuiToris> ultrafast was big and ugly while veryslow was smaller and nicer (with the same crf value) [21:56:39 CET] <JEEB> yes, the CRF values' results differ between presets [21:56:47 CET] <JEEB> since the preset enables and disables 'eyes' [21:57:42 CET] <GuiToris> I was wondering if let's say crf 28, preset ultrafast is equal to crf 30, preset veryslow [21:58:07 CET] <JEEB> there is no straight relevancy [21:58:25 CET] <JEEB> just pick like 2500 frames or so of a clip that show you what sort of content you're encoding [21:58:28 CET] <JEEB> then decide on your preset [21:58:32 CET] <JEEB> then tweak CRF [21:58:34 CET] <JEEB> that is it [22:01:01 CET] <GuiToris> that's exactly what I did, then it took about 23h to encode the final video, and I wasn't content with the result. I used x265, crf 30 and slower preset. I didn't know which value should I modify and also keep a small filesize [22:01:32 CET] <GuiToris> in the end I chose crf 28, and hoping it'll be good [22:03:04 CET] <GuiToris> during the tests I saw color banding with ultrafast but I didn't with veryslow. I was thinking that it didn't actually improve the quality it just use some kind of blur [22:03:07 CET] <JEEB> GuiToris: that is why you look at the result of those 2500 or so frames? and you make sure you try to see that it looks like a point in the video that is actually of relevant type/movement etc for the rest of that sort of content you are going to encode [22:03:15 CET] <JEEB> also x265 is completely different from x264 internally btw [22:03:35 CET] <JEEB> so any specifics regarding other than x265 has something called crf and something called presets [22:03:43 CET] <JEEB> goes out of the window :P [22:03:46 CET] <JEEB> also x265 can have bugs [22:03:59 CET] <JEEB> in any case, just use relevant samples for the actual CRF tweaking [22:04:00 CET] <GuiToris> I read that x264 crf 23 ~ x265 crf 28 [22:04:21 CET] <JEEB> I have no idea. the ranges were quite different the last I checked x265 [22:04:38 CET] <JEEB> while x265 can use x264's code because of the licensing agreement [22:04:45 CET] <JEEB> it's still very, very different [22:04:56 CET] <JEEB> of course the general idea should still match [22:05:12 CET] <JEEB> pick preset, use actually relevant sample of 2500-3000 frames to test CRF values with [22:07:17 CET] <GuiToris> JEEB: I'd have liked to compare frames. I used something like $ffmpeg -ss 2 -i input -frames 1 output.png does this keep the actual quality? [22:07:39 CET] <GuiToris> I'm not sure whether png modifies the image [22:07:48 CET] <JEEB> for comparison you can use something like vapoursynth editor with ffms2 [22:08:00 CET] <JEEB> has preview, is frame exact etc [22:08:19 CET] <GuiToris> I'll check it, thank you [22:08:45 CET] <GuiToris> does ffmpeg have a similar tool? [22:09:10 CET] <JEEB> no since FFmpeg by itself is not frame exact. you can use video players like mpv for *some* containers, but they make no promises [22:09:30 CET] <JEEB> ffms2 for example indexes the files with FFmpeg's APIs and makes things frame exact by keeping an index [22:10:16 CET] <JEEB> also you can use vapoursynth to do the clip cutting and then you can pipe the output of that vapoursynth script into ffmpeg.c with vspipe [22:10:33 CET] <JEEB> so you can cut different short clips of the longer clip you were going to test your parameters with [22:10:53 CET] <JEEB> because it makes no sense to wait for hours just to figure out if a CRF value is good enough at a certain preset for your content [22:11:16 CET] <GuiToris> it seems vapoursynth is superior to ffmpeg [22:11:17 CET] <JEEB> of course -ss and -t with ffmpeg.c does the same thing with ffmpeg.c if you only need a single clip [22:11:26 CET] <JEEB> vapoursynth is different [22:11:36 CET] <JEEB> and source modules for vapoursynth of course use FFmpeg [22:11:40 CET] <JEEB> the APIs that is [22:11:48 CET] <JEEB> because there's nothing like FFmpeg handling random multimedia [22:12:00 CET] <JEEB> but then vapoursynth is a frame server :P [22:13:00 CET] <GuiToris> thank you for your help [22:13:03 CET] <GuiToris> one last thing [22:13:12 CET] <GuiToris> is flac also a container? [22:13:27 CET] <JEEB> pretty sure what "flac" generally is is FLAC audio in ogg? [22:13:47 CET] Action: JEEB checks libavformat [22:14:12 CET] <GuiToris> My audio files are named something.flac rather than something.ogg [22:14:19 CET] <c_14> isn't flac raw? [22:14:28 CET] <JEEB> oh, just looked through lavf/flacdec.c [22:14:37 CET] <JEEB> it might actually be raw FLAC with a header [22:14:46 CET] <JEEB> also > 2001 copyright header [22:14:51 CET] <JEEB> ye olden times' code [22:15:53 CET] <GuiToris> I only named them ogg when I used vorbis [22:16:34 CET] <GuiToris> I've never used opus but I think I would name it also something.opus, which might not be correct [22:17:01 CET] <c_14> .ogg and .opus are both fine, .opus is an extension for "opus in ogg" [22:17:24 CET] <JEEB> yes, they stopped trying to do raw audio I think [22:17:38 CET] <JEEB> which is a good thing because containers generally let you do stuff like seeking [22:18:05 CET] <GuiToris> so, is .flac also fine? I don't have to use ogg, do I? [22:18:56 CET] <c_14> .flac is what's normally used, but you can pack it into a container if you want [22:20:27 CET] <GuiToris> thank you so much [22:42:48 CET] <trashPanda_> Hello, I am attempting to read in a rtsp stream with ffmpeg and I get numerous "Error parsing AU headers" errors. I am able to view the stream in ffplay, but I want to restream it via ffmpeg. [22:42:57 CET] <trashPanda_> the command line I'm using is [22:43:27 CET] <trashPanda_> "ffmpeg -fflags nobuffer -rtsp_transport udp -i (sourceaddress) -vcodec copy -f mpegts (outaddress) [22:43:35 CET] <Hello71> youtube prefers opus in matroska, dunno why [22:43:40 CET] <Hello71> maybe it's a hls requirement or something [22:43:48 CET] <Hello71> er, not hls, the other thing [22:43:55 CET] <Hello71> dash [23:27:18 CET] <BlackBishop> for a 'Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)' 'Duration: 02:18:17.50, start: 0.000000, bitrate: 71665 kb/s' I assume I'd need a 71mb/s connection, right ? [23:27:40 CET] <BlackBishop> which should be well within a 802.11ac connection, right ? [23:29:57 CET] <JEEB> hope that your connection actually goes that fast [23:30:33 CET] <JEEB> I think I was able to remux some ultra hd blu-rays into mp4 and then tried streaming them off through wifi onto my TV [23:30:46 CET] <JEEB> but with blade runner f.ex. it just didn't work very well [23:31:00 CET] <JEEB> so I do recommend a cable when possible [23:31:43 CET] <BlackBishop> the AP can do it .. https://www.ubnt.com/unifi/unifi-ap-ac-pro/ [23:31:59 CET] <BlackBishop> and I just noticed, I can play it just fine over http on my macbook pro ( on vlc ) [23:32:14 CET] <BlackBishop> but not on the tv ( sony kd-55xf9005 ) [23:32:23 CET] <BlackBishop> so it's not the wifi [23:32:28 CET] <JEEB> welcome to plastic boxes [23:32:47 CET] <BlackBishop> it also plays great when on usb in the tv :| [23:33:03 CET] <JEEB> wow, in my case the USB input seems worse off than network :P [23:33:14 CET] <BlackBishop> the usb plays perfect. [23:33:47 CET] <BlackBishop> the wire does seem better than the wifi though [23:34:04 CET] <BlackBishop> I tried ssh/ftp/http/nfs, nfs seems to be the best of all [23:34:16 CET] <BlackBishop> but it still stutters and at some point it totally looses audio. [23:36:38 CET] <BlackBishop> let's see if vlc will do a better job than kodi over http [23:45:54 CET] <BlackBishop> vlc doesn't want to play it at all... [23:49:31 CET] <AlexMax> Hi folks. Got a question. From what I understand, FFMPEG can use hardware acceleration to decode h264. However, I'd like to do this from a library. I'm trying to repurpose some existing h264 code, but the problem is that I'm not exactly sure how I'm suppsoed to specify "Hey, please fetch the h264 decoder that is mmal-accelerated". [23:50:12 CET] <AlexMax> ffmpeg lists the decoder as "h264_mmal" [23:50:30 CET] <JEEB> all hwaccels can have some specifics because they might need outside init for system-specific contexts etc, but if it's not a hwaccel then it's "just a decoder" [23:51:04 CET] <AlexMax> Well, I think I have to use -hwaccel to get the decoder to show up [23:51:17 CET] <AlexMax> well...actually... [23:51:31 CET] <AlexMax> if I do ffmpeg -codecs, i get: [23:51:53 CET] <AlexMax> DEV.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_mmal h264_vdpau ) (encoders: libx264 libx264rgb h264_omx h264_vaapi ) [23:52:09 CET] <JEEB> yea, so try to get the AVCodec by name with the _mmal [23:52:21 CET] <AlexMax> JEEB: Tried that, got an error [23:52:24 CET] <JEEB> ok [23:52:25 CET] <AlexMax> avcodec_find_decoder_by_name("h264_mmal"); right? [23:52:31 CET] <JEEB> yea [23:52:36 CET] <AlexMax> some codec not found error [23:53:15 CET] <AlexMax> "Couldn't find decoder" was the specific error [23:54:04 CET] <AlexMax> To be frank, I know very little about the ffmpeg API and I've been repurposing some existing working code that was built for nearly my exact use-case [23:54:55 CET] <AlexMax> but in the old codebase, ffmpeg was not used to hardware-decode on the raspberry pi, presumably because the ffmpeg provided didn't support it [23:55:21 CET] <AlexMax> Now it does, and I want to reduce code complexity by having as much stuff as possible funnel through ffmpeg [23:55:43 CET] <AlexMax> with maybe a non-ffmpeg fallback on windows [23:56:52 CET] <JEEB> windows has d3d11 and dxva2 [23:57:05 CET] <JEEB> *d3d11va [23:58:48 CET] <AlexMax> Well, more to not have an ffmpeg dependency on windows - building stuff on windows is a pain anyway, and at the end of the day I need a single .dll file with no other depenedncies [23:59:16 CET] <JEEB> dunno, mingw-w64 works comfy enough for me [23:59:32 CET] <JEEB> the only thing I hate about windows dev is that there's no valgrind [23:59:37 CET] <AlexMax> I dunno, that's kinda beside the point [00:00:00 CET] --- Thu Nov 15 2018

1 0

ffmpeg-devel.log.20181113
by burek 14 Nov '18

14 Nov '18

[08:17:28 CET] <cone-337> ffmpeg 03Tobias Rapp 07master:7992c2867efc: avcodec/libopenh264enc: fix class_name [11:40:01 CET] <cone-428> ffmpeg 03Martin Vignali 07master:13ee107afd3d: avcodec/prores_metadata_bsf : fix colorspace check [12:42:29 CET] <thardin> that sscanf() solution sure is something [12:55:03 CET] <thardin> there has to be a better solution that reimplementing it or fork()ing [12:56:16 CET] <durandal_1707> no [12:59:31 CET] <thardin> fflibc when? [13:02:29 CET] <thardin> my inner formal verifier cries a little looking at code like this [13:30:05 CET] <BtbN> locale issues with printf/scanf are a huge pain, and there really does not seem to be a proper solution [13:30:26 CET] <BtbN> You'd wish there'd be something like disable_locale() reenable_locale() you can just slap around it [13:35:00 CET] <thardin> that wouldn't be reentrant [13:35:17 CET] <BtbN> depends on if it's set globally or thread local [13:35:26 CET] <thardin> right [13:36:09 CET] <thardin> this reminds me of errno, and the efforts to try and make it less annoying [13:36:37 CET] <thardin> a libified libc (liblibc if you will) would be useful [13:36:37 CET] <BtbN> errno just seems like a design flaw that somehow dragged on to me [13:38:06 CET] <durandal_1707> tell him that: https://github.com/wm4/libinsanity [13:41:01 CET] <thardin> gpl might be a hindrance (not for me though) [16:33:54 CET] <orbea> Hi, I am having a segfault in the ffmpeg master (as of a few days ago) and older releases when running a single alephone scenerio (game). Here is a backtrace https://pastebin.com/YZ1qSnCC and the alephone issue. https://github.com/Aleph-One-Marathon/alephone/issues/121 My question, is this an ffempg bug or an alephone bug? maybe it could be both? [16:35:01 CET] <orbea> my limited understanding its crashing on an audio frame [16:44:37 CET] <jamrial> orbea: https://github.com/Aleph-One-Marathon/alephone/blob/master/Source_Files/FFm… [16:44:40 CET] <jamrial> sizeof(AVFrame) is not a part of the public ABI [16:45:11 CET] <jamrial> they should allocate a frame with av_frame_alloc(), and not in stack [16:47:09 CET] <jamrial> it's crashing because that frame on stack is uninitialized [16:50:40 CET] <orbea> ah, thanks! [16:50:54 CET] <orbea> I'll make sure that is conveyed to the alephone devs [16:51:25 CET] <orbea> would you mind if I quoted irc for that issue? [16:58:23 CET] <atomnuker> its written in libavutil/frame.h, line 219 in current git master [16:59:31 CET] <orbea> oh, thanks. *looks for the comments* [17:17:20 CET] <JEEB> durandal_1707: finally got some time to test things, and seems like it isn't framesync2 since if I take upstream + revert my first attempt at fixing the sub2video issue (e760c12aeef608aa8b416664687b9aca3a2c6f68) then the performance seems good [17:17:55 CET] <JEEB> it's most likely one of hte sub2video things I've posted since on the ML [17:19:10 CET] <JEEB> I was going to say that it's funny because the affected input had no subtitles to begin with, but oh yes it did :P [17:24:33 CET] <JEEB> it's not completely derped though, since another thing has now run N inputs and two with subtitle overlay [17:24:54 CET] <JEEB> but yea, will be doing more does it vs does it not testing [18:43:15 CET] <durandal_1707> anybody have dot-crawl samples to share? [18:43:59 CET] <atomnuker> yeah, JEEB had one [18:45:39 CET] <atomnuker> https://fushizen.eu/u/jeeb/derp/00002.MPS [18:46:31 CET] <JEEB> ah yes, that's why it popped up during the PSP video discussions [18:46:41 CET] <atomnuker> you'll need to deinterlace, but the dot crawl is monsterous [18:46:56 CET] <JEEB> mistagged full range, dot crawl, ATRAC3+ in MPEG-PS [18:50:44 CET] <atomnuker> eh? the file has audio? [18:51:41 CET] <JEEB> yes [18:51:50 CET] <JEEB> if you apply mistydemeo's patch it probably sounds [18:52:10 CET] <JEEB> although last I checked the parser or something barfs if you try to seek [18:53:16 CET] <atomnuker> where did you get that, can't be from a dvd [18:53:45 CET] <JEEB> UMD Video [18:53:55 CET] <atomnuker> didn't know that was a thing [18:54:06 CET] <JEEB> oh yes, I also have Spiderman on it [18:54:14 CET] <JEEB> since Sony gave them out if you registered your PSP [18:54:14 CET] <JEEB> :D [18:59:04 CET] <gnafu> Classic. [19:24:02 CET] <BBB> michaelni: do you remember what the ffmpeg flag is called to not scale frames? e.g. if the input is scalable, and I want the output frames to be variably scaled also, you mentioned an option a few years back to not scale to one standard size in the output stream, what was that called again? [20:23:51 CET] <michaelni> BBB,i think you refer to "-reinit_filter 0" the intend of that flag IIRC was to send input changes into the filter graph so the filter graph could handle them in any way choosen without loosing state. If the filter graph didnt remove the change then it would be passed on the encoder this was more a sideeffect and possibly usefull but not why the flag was there. It seems the flag doenst work in master anymore [20:26:51 CET] <BBB> ok, thanks, little bit unfortunate but Ill find some other way then [20:26:55 CET] <BBB> thanks for answering [20:50:43 CET] <durandal_1707> anybody against ffvhuff patch? i gonna push it now! [21:43:12 CET] <kierank> durandal_1707: if you are bored you can finish this patch https://trac.ffmpeg.org/ticket/7163#comment:7 [21:54:11 CET] <durandal_1707> kierank: that patch is incomplete [21:54:25 CET] <kierank> "Here is unfinished patch" [21:54:27 CET] <kierank> no shit [21:55:04 CET] <durandal_1707> kierank: unfinished patch is incomplete [21:55:19 CET] <durandal_1707> partial [21:55:28 CET] <durandal_1707> missing some code i think? [21:55:37 CET] <kierank> 12-bit alpha [21:55:52 CET] <durandal_1707> not that [21:57:27 CET] <durandal_1707> do we have 12 bit idct [21:58:47 CET] <kierank> we do [21:58:52 CET] <kierank> that patch produces clean output [22:03:52 CET] <durandal_1707> kierank: write simd code [22:04:10 CET] <kierank> maybe at christmas [22:15:34 CET] <cone-428> ffmpeg 03Andreas Rheinhardt 07master:959521b58de9: h264_levels, h264_metadata_bsf: Fix levels typo [22:15:35 CET] <cone-428> ffmpeg 03Andreas Rheinhardt 07master:3c9c9b1568ef: h264_metadata: Don't use inferred value of buffering frames [23:01:38 CET] <cone-428> ffmpeg 03Michael Niedermayer 07master:6b4c9854daba: avcodec/golomb: Speed up long ur_golomb codes [23:01:39 CET] <cone-428> ffmpeg 03Michael Niedermayer 07master:2f888771cd1c: avcodec/shorten: Fix integer overflow with offset [00:00:00 CET] --- Wed Nov 14 2018

1 0

ffmpeg.log.20181113
by burek 14 Nov '18

14 Nov '18

[00:06:34 CET] <auri_> Hello! I'm currently working with ffmpeg (cli) doing MPEG-DASH encoding/segmentation of lossless (FLAC) audio and have encountered interesting behaviour - it sets "codecs" xml attribute (part of MPD.Period.AdaptationSet.Representation) to "fLaC" and not "flac", where latter is the only way browsers accept it [00:07:18 CET] <auri_> command is `ffmpeg -i <infile.flac> -c:a copy -strict -2 -f dash manifest.mpd`, nothing fancy [00:08:14 CET] <JEEB> hint 1: -strict -2 is actually "-strict experimental" [00:08:31 CET] <JEEB> otherwise i think it's a mktag issue [00:08:51 CET] <BtbN> I think that's the official fourcc for flac [00:09:11 CET] <JEEB> yea, the ogg/flacdec lavf things use that identifier [00:09:14 CET] <JEEB> fLaC [00:09:31 CET] <auri_> if thats the case, should I report it as a bug to mozilla since firefox doesn't accept it? [00:09:39 CET] <JEEB> no, that's separate [00:09:45 CET] <JEEB> need to find the specification for it [00:10:22 CET] <JEEB> https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txt [00:10:33 CET] <JEEB> > + The codingname of the sample entry is 'fLaC'. [00:10:45 CET] <JEEB> ok, so the mp4 side sample entry identifier is that [00:12:31 CET] <auri_> I was hesitant to ask here because its just the browsers that won't accept it [00:12:40 CET] <auri_> players like vlc and mpv play it back just fine [00:12:48 CET] <JEEB> yes, because mpv f.ex. just uses lavf [00:12:55 CET] <JEEB> VLC has its own mp4 demuxer [00:13:15 CET] <JEEB> but it seems like it was never properly finalized, and the specification doesn't touch the DASH manifest side [00:13:39 CET] <auri_> oh, its always good to stumble on undocumented behaviour [00:13:50 CET] <auri_> right now I just modify the manifest myself [00:14:01 CET] <auri_> s/fLaC/flac/ so all players accept it [00:14:17 CET] <JEEB> yes, so they clearly take teh identifier fLaC inside the container [00:17:10 CET] <JEEB> auri_: I see a manual string identifier in dashenc.c [00:18:09 CET] <JEEB> if you want to test it try adding this line http://up-cat.net/p/6b76769f [00:18:47 CET] <JEEB> if that works then that might just be worth a patch since we've got at least one (1) user [00:19:21 CET] <auri_> lemme build it real quick [00:19:30 CET] <auri_> I'll be back with the results in ~10 minutes [00:22:06 CET] <auri_> JEEB: that worked [00:22:25 CET] <auri_> it now outputs a proper codecs attribute [00:23:11 CET] <JEEB> I'd like that identifier be specified somewhere, although I guess it might be something browser-side/generic content type identifier [00:23:33 CET] <JEEB> but great to know that that's enough for it [00:23:33 CET] <auri_> whatwg wiki says it should be codecs=flac [00:23:44 CET] <auri_> *shrug* [00:23:53 CET] <auri_> oh yes while I'm still here [00:25:14 CET] <auri_> was there ever patch for an option like -initial_offset (-f segment) for dashenc [00:25:38 CET] <auri_> I know Plex fork has it and I skimmed over their impl, seems simple enough [00:26:02 CET] <JEEB> oh yes, people seem to really like that on the muxer side while in general they should just be offsetting their input timestamps a la -itsoffset [00:26:23 CET] <JEEB> (itsoffset being an ffmpeg.c option) [00:26:45 CET] <auri_> that changes segment filenames? [00:26:58 CET] <JEEB> well that sounds like the initial timestamp offset, no? [00:27:03 CET] <JEEB> so that timestamps don't start at zero [00:27:15 CET] <auri_> makes sense yeah [00:27:33 CET] <auri_> so after all the option is there, just in a different way [00:27:49 CET] <auri_> thanks for letting me know [00:27:51 CET] <JEEB> there's a generic ffmpeg.c option for it, but I think you need to utilize -copyts with it or so [00:28:03 CET] <JEEB> or some other -vsync mode than the default [00:28:23 CET] <JEEB> vsync is just a fancy wording for ffmpeg.c dropping or duplicating frames :P [00:28:34 CET] <JEEB> (also the logic can make a grown man cry) [00:28:40 CET] <auri_> I'll see what I can do with it tomorrow, EU times suck [00:28:53 CET] <auri_> basically I need it to handle seeking in a streaming application [00:29:08 CET] <auri_> kill ffmpeg -> restart wit -ss and skipped segments [00:29:37 CET] <auri_> unless there's a better way to handle it I'm not aware of [00:31:43 CET] <JEEB> at some point using the APIs becomes a viable alternative [06:45:59 CET] <KombuchaKip> Hey everyone. I'd really appreciate a code review of my custom AVIOContext for reading media from memory: https://pastebin.com/NGALFw8Y [11:13:36 CET] <termos> I have an incoming stream where time `pts` of the audio and video is out of sync by a constant amount, is there a way to fix this somehow? [11:14:27 CET] <termos> I thought of offsetting one of them by the difference of `pts` in the first incoming packages, but they always seem to have `pts` 0 [11:29:52 CET] <ponyrider> seems like there is a well known issue surrounding trimming a video with -c copy? what is the work around for this? [11:30:24 CET] <ponyrider> the command i have is: ffmpeg -i video.mp4 -ss 00:00:10 -to 00:00:15 -c copy output.mp4 [11:31:14 CET] <durandal_1707> you cant trim exact with copy, it just can not work with lossy encodes with inter frames [11:31:44 CET] <ponyrider> SO says: ffmpeg -ss 191 -i vid.mp4 -vcodec libx264 -acodec libmp3lame -t 6 someoutput3.mp4 [11:32:01 CET] <ponyrider> to re-encode. is this what you would recommend? [11:32:27 CET] <ponyrider> durandal_1707: ^ [11:33:04 CET] <durandal_1707> re-encode will degrade quality [11:33:16 CET] <durandal_1707> with above line [11:33:41 CET] <ponyrider> what is the solution to get a more precise trim as lossless as possible? [11:34:02 CET] <Mavrik> Black magic? [11:35:16 CET] <ponyrider> i just want to trim youtube videos ... :\ [11:36:01 CET] <Mavrik> Noone is stopping you, but there are fundamental limitations around trimming videos stored in modern formats. [11:36:11 CET] <Mavrik> And caring about lossless trimming for YT content is a bit wierd. [11:36:21 CET] <ponyrider> well i dont mind about the losses so much [11:36:32 CET] <ponyrider> just a precise trim. sometimes it works. sometimes it doesnt [11:39:43 CET] <furq> ponyrider: -ss 123 -i foo.mp4 -t 456 -c:v libx264 -crf 20 -c:a copy out.mp4 [11:39:58 CET] <furq> also you probably want to download vp9 from youtube if you're doing further editing to it [11:41:03 CET] <ponyrider> alright if that's the best answer i will take it! [11:41:29 CET] <furq> idk about best but it works and it's not a huge amount of hassle [11:41:54 CET] <furq> in an ideal world you'd only reencode the first and last gop and then stitch it together [11:42:07 CET] <furq> but that is a lot of hassle and if you're clipping six seconds then there's only going to be one or two gops anyway [11:44:36 CET] <ponyrider> i just want accurate trim w no hassle thank you v much [12:00:59 CET] <ponyrider> the -to option is faulty [12:01:08 CET] <ponyrider> its giving me a video of 44 seconds longs [12:02:21 CET] <furq> -to has to be in the same place as -ss [12:02:35 CET] <furq> -ss as an input option and -to as an output option doesn't work [12:02:39 CET] <furq> or it does, but it just does the same thing as -t [12:02:42 CET] <ponyrider> i see so -ss cannot go before -i? [12:02:51 CET] <furq> put them both before -i [12:03:00 CET] <furq> or both after, i don't think it matters if you're reencoding the video [12:03:18 CET] <furq> but yeah -ss/-t/-to behave differently depending on whether they're input or output options [12:04:03 CET] <relaxed> isn't -ss more accurate when placedafter the input -i ? [12:10:57 CET] <ponyrider> ok furq its working well the quality is not any worse either thanks man [12:14:34 CET] <furq> relaxed: i don't think it matters if accurate_seek is enabled [12:14:37 CET] <furq> which it is by default [14:58:54 CET] <somy> hi [14:59:31 CET] <somy> I'm trying to modify ffplay to use hwdec on rockchip and I'm a bit lost [15:00:55 CET] <somy> It' doesn't output anything, I must do something wrong but as soon as it uses the queues to store decoded stuff I get no image.. [15:01:12 CET] <somy> any pointers on where to look for ? [15:55:40 CET] <plalorenz> I want to create a video from images. Let's say I have 1000 images that are named like: "index_dynamic_dynamic_dynamic_dynamic.jpg" so index would go from 0 to 999 and dynamic parts of the file name would be various information. I have tried to create the video with this command: https://pastebin.com/FDwmPX72 but it's not sequential. I know that I am able to say %d in the file name, but how do I mix %d with *? [17:03:00 CET] Last message repeated 1 time(s). [18:22:17 CET] <KombuchaKip> Hey everyone. I'd really appreciate a code review of my custom AVIOContext for reading media from memory: https://pastebin.com/NGALFw8Y [19:01:35 CET] <Hello71> pretty sure that already exists [19:01:46 CET] <Hello71> also eww c++ [19:19:38 CET] <KombuchaKip> Hello71: Sorry, what already exists? [21:29:48 CET] <somy> Does anybody know howto use av_frame_ref / unref / free in hwdec context? [21:50:30 CET] <BtbN> Same way as usual? [21:55:13 CET] <somy> I'm a bit lost either I get a double free, if I use free or the hwedc "explode" trying to free leaked data (because they weren't freed... [22:44:17 CET] <leif> So, is `av_register_all` no longer required to call for ffmpeg 4? [22:46:21 CET] <JEEB> yes [22:46:59 CET] <JEEB> the list is static nowadays since the ability to register formats during run-time was not possible to use from the outside (since it required private symbols) [22:48:17 CET] <leif> JEEB: makes sense. So basically programs can work otherwise the same, just without calling it?) [22:49:19 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/APIchanges;h=db1879e6e23… [22:49:44 CET] <JEEB> search around that for av_register_all and see the notes about newly added functions [22:49:50 CET] <JEEB> but generally, yes [22:53:31 CET] <leif> JEEB: okay cool, thanks. [23:30:42 CET] <Pdrome> Hi is the the right place to ask a question about FFmpeg? [23:31:11 CET] <JEEB> yes [23:32:23 CET] <Pdrome> Thanks. I wanted to ask: Does FFmpeg use any code owned by RAD Game Tools? [23:32:45 CET] <JEEB> not that I know. all of the closed source stuff as far as I know has been reverse engineered [23:33:48 CET] <JEEB> so unless a) RAD game tools contributed some code to FFmpeg (under LGPL) or b) someone got access to RAD Game Tools code and put it in , there should be no RAD Game Tools code in FFmpeg [23:34:26 CET] <JEEB> after reading your question I had to add case a) as well, since I own the copyright to the code I contribute to FFmpeg [23:34:27 CET] <Pdrome> The reason I ask is that I was doing research into gamedev about 2 years ago and found a mailing list entry whereby the FFmpeg devs had got hold of RAD Game Tools source code maybe through a leak etc and I wanted to know what the llegal situation is there ragrding FFmpeg [23:35:39 CET] <pink_mist> the legal situation is that the ffmpeg devs would not be allowed to use said code unless RAD Game Tools specifically gave them a license to do so [23:35:52 CET] <JEEB> yes [23:36:34 CET] <JEEB> but if someone just studied the code and wrote his own, that is the author's thing. [23:36:46 CET] <JEEB> although that's still less kosher than RE [23:37:07 CET] <Pdrome> controversial question I know, but I am hesitant to use FFmpeg for commercial projects given my findings as I dont know if the FFmpeg project could be liable and in turn myself for using FFmpeg. [23:37:47 CET] <JEEB> nothing much controversial about it. [23:38:15 CET] <pink_mist> pretty sure all the code in ffmpeg has been thoroughly vetted so that the authors have given the appropriate license for the code [23:38:20 CET] <JEEB> if someone else's code was used verbatim that's always bad [23:38:29 CET] <Mavrik> Sue Google, see what they say, resolve once and for all :P [23:38:47 CET] <JEEB> if you can provide a reference and ask for details on the mailing list or the issue tracker that could get the ball rolling [23:40:37 CET] <Pdrome> JEEB are you a dev? I can post the mailinglist link regarding the source code possible usage [23:41:07 CET] <Pdrome> It was FFmpegs own mailing list btw. Let me just refind it... [23:41:28 CET] <JEEB> Pdrome: also for the record the history between one of the people implementing RAD game tools' formats and RAD Game Tools seemed to be generally positive. they seemed to winkingly link info on new bink formats etc to the guy [23:42:52 CET] <JEEB> and if someone would come after you for using FFmpeg it'd probably be the IP owners for actually standardized formats [23:43:01 CET] <JEEB> as opposed to something like RAD [23:43:05 CET] <JEEB> IANAL of course [23:44:35 CET] <Pdrome> cheers JEEB, I am slightly reassured. Would love to get input from contribs regarding the mailing list entry I found. Still looking for it... [23:44:45 CET] <JEEB> sure, agree with that [23:49:19 CET] <Pdrome> Doh! Can't find it by re-googling but here's an interesting quote: [23:49:21 CET] <Pdrome> Rad Game Tools claimed that the MPC interface to the DLLs was based on leaked/proprietary information which is why they compelled MPC to remove support. But not before I reverse engineered and documented the DLL interfaces: see http://wiki.multimedia.cx/index.php?title=RAD_Game_Tools_Bink_API and http://wiki.multimedia.cx/index.php?title=RAD_Game_Tools_Smacker_API . RGT once contacted me and requested that I remove those descriptions fr [23:49:41 CET] <Pdrome> from here: https://multimedia.cx/eggs/bink-video-in-ffmpeg/ [23:50:06 CET] <Pdrome> I must have the mailing list entry bookmarked on another machine [23:50:25 CET] <JEEB> ok, FFmpeg doesn't utilize the official RAD APIs [23:50:49 CET] <JEEB> that talks about the interfaces against RAD's own libraries [23:51:14 CET] <JEEB> seems like at some point Gabest's MPC (the media player I guess) had support for the APIs [23:51:43 CET] <Pdrome> I am gutted I can't find the mailinglist entry - it was very clear [23:52:13 CET] <Pdrome> When I do find it I will pop back and post again, thanks so far though for your adive and thoughts [23:52:48 CET] <JEEB> so basically what that means is that mpc used interfaces (probably headers) which were leaked and not under an open source license, and thus incompatible with being in an open source thing (like MPC) [23:53:07 CET] <JEEB> and those interfaces are against RAD's binkw*.dll I guess [23:53:27 CET] <JEEB> now, FFmpeg's stuff is of course completely separate from the bink DLLs [23:54:20 CET] <Pdrome> Here's a hypothetical... If FFmpeg did use RADs algorithms etc, would that be illegal if it was acquired through means of a RAD game tools source code leak from somewhere? [23:55:07 CET] <JEEB> if the code was verbatim RAD code then that's not kosher [23:55:17 CET] <Pdrome> as my above is closest to what I remember the mailing list alluded to [23:57:13 CET] <JEEB> that said, since it's kostya I'd find it rather unlikely that he would have done something like that. esp. given him having fans (?) within RAD seemingly sending him challenges ("psst, did you know that we have *another* new format around? ;)") [23:57:41 CET] <JEEB> and given that he's rather capable in actual RE as it's become obvious during the years [23:57:57 CET] <JEEB> doesn't make it an impossibility of course [23:59:26 CET] <JEEB> hah, he has just started poking at real's new china format according to his own blog :P [23:59:31 CET] <Pdrome> that is my other thought... where would the FFmpeg project stand if it uses rads source code from a leak but it is just rewritten etc + if other aspects not leaked were reverse engineered? [00:00:00 CET] --- Wed Nov 14 2018

1 0

ffmpeg-devel.log.20181112
by burek 13 Nov '18

13 Nov '18

[01:14:07 CET] <cone-065> ffmpeg 03Andreas Rheinhardt 07master:ee47ac97d793: cbs_h2645: Improve performance of writing slices [01:26:37 CET] <philipl> BtbN: do you think it's ok as a single change or should break out the updates for each codec/filter? [01:56:27 CET] <iive> if you do that, would it help bisect or would it make it slower? [02:23:44 CET] <philipl> I think it makes little difference. The most likely problem is I goof one of the codecs/filters and it segfaults. You'd know which change to look that either way. [09:42:27 CET] <cone-674> ffmpeg 03Paul B Mahol 07master:a09411a0ee02: avfilter/af_afftfilt: calculate all channels FFT values upfront [09:42:28 CET] <cone-674> ffmpeg 03Paul B Mahol 07master:0f2cfa3d809b: avfilter/af_headphone: do not leak input frames on error [09:46:00 CET] <cone-674> ffmpeg 03Paul B Mahol 07master:26772b789b95: avcodec/tiff: add initial bayer and sub image support [09:54:13 CET] <durandal_1707> no reviewers - dead project [10:28:43 CET] <dualz> so I have a filter that passes through a video and an audio input 2->2. I am using activate(). My question is there a good guide on syncing audio and video? Looking at my activate callback does it look like the frames are going to get out of sync? https://gist.github.com/ryanmarin/86808a7ea2eccd8117f7855dfdf412e9 [10:29:40 CET] <durandal_1707> it will get out of sync if you do not look at pts [10:31:48 CET] <dualz> what am i supposed to do after I look at them [10:33:48 CET] <durandal_1707> depending on inlink and outlink timebase change pts, but synchronization is done via pts, so i fail to see what you want to do with that filte [10:33:51 CET] <durandal_1707> *filter [10:39:09 CET] <dualz> the filter takes in a video and an audio input (some constant stream such as nullsrc), when it starts it simply passes through the input to the output. Then it has a process_command for opening a file, while the file is open it passes on it's av frames to the output instead of passing through the input. Once that file EOFs it falls back to passing through the inputs [10:39:19 CET] <BtbN> philipl, seems fine to me as one change, but no strong opinion there [10:41:19 CET] <durandal_1707> dualz: then you will need to always change frame pts, if you want to pts appear monotonous(no gaps) and increasing in output [10:43:44 CET] <dualz> is there any filter I can look at that does similarly to what I need? [10:45:22 CET] <cone-674> ffmpeg 03Steven Liu 07master:43cc2e39c009: avformat/hlsenc: check dirname and fix vtt problem [10:45:29 CET] <durandal_1707> dualz: another issue are what about if videos are VFR [10:45:57 CET] <durandal_1707> dualz: look at tpad and loop filters how they change pts [10:50:50 CET] <cone-674> ffmpeg 03Paul B Mahol 07master:29f2893318a2: avfilter/vf_alphamerge: switch to activate [11:35:15 CET] <m2adave> Hello! For our project, we need ATSC AC3 descriptors in the MPEGTS output. This has been discussed before in https://trac.ffmpeg.org/ticket/5837 (associated discussion at http://ffmpeg.org/pipermail/ffmpeg-user/2016-September/033536.html) and https://trac.ffmpeg.org/ticket/2162. [11:35:15 CET] <m2adave> I've started looking at mpegtsenc.c, and adding the registration descriptor is straightforward enough, but adding the AC-3_audio_stream_descriptor (0x81) is complicated because it needs bitstream parameters (bsid, bsmod, acmod etc), and there's no extradata available for AC-3. [11:35:15 CET] <m2adave> Can anyone suggest a way I can access the required parameters? I note that movenc waits for a packet of AC3 and then parses the header, which seems reasonable, but I'm not sure how this works in a streaming scenario where the header should be available before the data. In MPEGTS, the PMT is potentially sent before the first AC3 packet has arrived anyway, so this doesn't seem like an option. [11:35:15 CET] <m2adave> It would be easy to stick the AC3 bsi in extradata or something, but I guess this isn't the right solution. [11:35:15 CET] <m2adave> Thanks in advance for your help. [11:37:21 CET] <nevcairiel> mpegts doesnt have any global headers anyway, its all in-stream, so waiting for data seems trivial to me [11:42:21 CET] <m2adave> @nevcairiel, thanks. That is an option but the problem is that a PMT will be sent at the beginning which does not correctly describe the stream (unless the first data packet sent is an AC3 packet). Then later, when the first AC3 packet arrives, either a forced SI update needs to occur at the first AC3 PES packet, or some packets would be missed. [12:14:48 CET] <cone-674> ffmpeg 03Jun Zhao 07master:991cd7915537: fate: Add test for vc1test demuxer [12:33:43 CET] <cone-674> ffmpeg 03Akemi 07master:233cd8905640: lavc/videotoolbox: Fix cropping with HEVC and H264 videos [12:35:39 CET] <cone-674> ffmpeg 03Paul B Mahol 07master:e96742dd3bdf: avfilter/af_afftfilt: use first input frame timestamp [12:43:50 CET] <cone-674> ffmpeg 03Mark Harris 07master:ae4323548ae8: avfilter/vf_fade: fix start/duration max value [12:49:09 CET] <dualz> durandal_1707: I'm looking at the loop filter and how it keeps the PTS in the context then increments it depending on the number of samples or duration of a frame [12:50:28 CET] <dualz> would I increment it by nb_samples every audio frame and pkt_duration every video? [12:53:08 CET] <durandal_1707> dualz: your case is simpler imho, you just output first inlink with pts from 0 and than when you receive input file you just offset input file pts with last pts you received from inlink [13:13:01 CET] <dualz> so in it's original state the audio and video should be in sync, it's only when I open files do I need to offset the PTS? [13:13:15 CET] <dualz> or am I confused [13:20:34 CET] <durandal_1707> you are not going to compare audio and video pts for sync [13:20:53 CET] <durandal_1707> this could be just V->V and A->A filter [13:22:53 CET] <durandal_1707> offset pts = increase evvery pts received from input file by same ammount received from last inlink, similar pts from inlink after input file finished would be increased by last pts of output frame [14:00:46 CET] <durandal_1707> so we want DOS support but not XP support? [15:09:37 CET] <j-b> Tested-by: ponpon [15:09:38 CET] <j-b> wtf [15:10:46 CET] <J_Darnley> Is there an x86 SIMD instruction that does both pshufd and blendps together [15:13:43 CET] <J_Darnley> A note for others: avoid opening the intel instruction set reference in LibreOffice Draw [15:15:17 CET] <atomnuker> J_Darnley: welp, you can shuffle in zeroes and OR whatever you need on there [15:20:58 CET] <J_Darnley> yeah I could [15:21:28 CET] <J_Darnley> probably best I keep it simple [15:21:52 CET] <J_Darnley> a pair of pshufd and movq [15:24:34 CET] <philipl> BtbN: https://github.com/philipl/mpv/tree/cuda-vkimage [15:25:23 CET] <philipl> BtbN: This is VkImage based interop. I think it should work on windows with 416.xx drivers, if you want to try it out. [15:35:49 CET] <BtbN> philipl, Does that allow bi-directional stuff? Probably now? [15:35:52 CET] <BtbN> *not [15:39:07 CET] <philipl> no [16:31:16 CET] <J_Darnley> what the hell? where is my return instruction? [16:51:25 CET] <Gramner> J_Darnley: shufps may be what you're looking for depending on what order you need the elements to be in [17:16:28 CET] <dualz> durandal_1707: taking it back a step to the original pass through, I am noticing a max of 10FPS to my output, this is my activate() logic: https://gist.github.com/ryanmarin/6b9e12d24b720ae8e485c497948a2926 [17:17:01 CET] <dualz> is there any reason i should be seeing a reduction in framerate [18:51:15 CET] <durandal_1707> dualz: no reduction in framerate for simple pass should happen [18:58:58 CET] <durandal_1707> no comments for av_sscanf expect usual suspects, so i can push it asap? [19:00:52 CET] <jamrial> durandal_1707: add a proper copyright and resubmit [19:00:57 CET] <jamrial> otherwise there will be drama [19:01:49 CET] <jamrial> don't mention every author if it's an impossible task, just state it's from musl [19:20:13 CET] <dualz> durandal_1707: I pasted the two commands I used to get different framerates: https://gist.github.com/ryanmarin/a8ef8cc5d7d8f9b74b2abd4d8b8b696a [19:48:12 CET] <durandal_1707> jamrial: done [19:49:47 CET] <durandal_1707> dualz: and what is CPU usage with feed filter? [19:52:32 CET] <atomnuker> durandal_1707: that'll fail fate, since fate checks for license header [19:53:09 CET] <durandal_1707> what? how? fix it how? [19:53:34 CET] <atomnuker> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186280.html [19:53:42 CET] <atomnuker> look at how I did the license header at the top [19:54:16 CET] <atomnuker> Just replace the xiph license with whatever musl had [19:54:33 CET] <durandal_1707> fate source passed here.... [19:54:52 CET] <durandal_1707> is not smart enough to detect dual license [20:19:48 CET] <durandal_1707> do we need %m in av_sscanf() ? [20:21:59 CET] <durandal_1707> atomnuker: jamrial said it maybe should be better to put this function in separate file, what you think? [20:23:45 CET] <atomnuker> that'd be fine, as long as its still exposed in avstring.h [22:10:25 CET] <cone-728> ffmpeg 03Paul B Mahol 07master:23f589e07340: avfilter/vf_alphamerge: do not check for ret value if all wanted frames are present [00:00:00 CET] --- Tue Nov 13 2018

1 0

ffmpeg.log.20181112
by burek 13 Nov '18

13 Nov '18

[00:55:07 CET] <foo> I'm wanting to convert an MP3 to FLAC (first 30 seconds) only. I can A) transcribe with ffmpeg on filesystem, store as flac, use file, then delete or B) I can do this all in memory somehow and never actually write the file to disk. Anyone happen to know which might be preferred? I know I can do A) really easy... but converting + deleting file sounds unnecessary if I can do it all in memory... although doing it all in memory may use more memory... ... [00:55:13 CET] <foo> ... originating mp3 file can be < 100MB [01:00:41 CET] <hololeap> foo: if you are in linux you could mount a tmpfs to the filesystem and get the best of both worlds [01:01:26 CET] <iive> why -t 30 is not working for your case? [01:01:57 CET] <foo> hololeap: I'm doing this in python, FWIW. I'll delete the resulting file afterwards [01:02:16 CET] <foo> iive: oh, ffmpeg -t 10 -i Jared.mp3 Jared.flac works fine [01:02:29 CET] <foo> I'm wanting to do this on the fly, use file once, then delete it... debating doing this in memory or on FS [01:03:10 CET] <hololeap> depending on your distro, a tmpfs (basically a RAM filesystem) may be mounted at /tmp, so if you store it there temporarily, it may never touch your disks [01:04:33 CET] <foo> hololeap: oh, interesting, I may not be familiar with this [01:04:47 CET] <foo> yeah, since I'm ultimately wanting to tie it into this... with io.open(file_name, 'rb') as audio_file: content = audio_file.read() ... [01:04:54 CET] <foo> I believe with python-flask I could do this too [01:04:56 CET] Action: foo investigates [01:07:37 CET] <somy> hi there, anybody has any experience using hwdec in the libs... I'm totally lost... it's half working I get all the frames in decode order that would be ok if the pts where not equals to the dts... [01:09:00 CET] <foo> hmm, anyone see what I'm doing wrong? https://paste.ofcode.org/tTgRrgUfwVrsNwgTNu5b6Z [01:09:07 CET] <foo> I may have to explicitly pass conversion from mp3 to flac [01:13:59 CET] <foo> ah, nevermind [01:15:27 CET] <foo> ]trim=duration=10[s0] matches no streams [01:15:49 CET] <foo> I see the filter here https://github.com/kkroening/ffmpeg-python/blob/master/ffmpeg/_filters.py [01:17:07 CET] <foo> .filter('trim', duration=10) looks right too. /me scratches head [01:22:17 CET] <foo> .filter('trim', start=0, end=10) still throws Stream specifier '' in filtergraph description [0]trim=end=10:start=0[s0] matches no streams. [01:22:20 CET] <foo> huh [01:27:19 CET] <foo> aha, got it [02:10:56 CET] <Buliarous> hey so i want to break a movie up into pieces using segments or something such that each piece is no larger than 128mb (maybe 120mb to be safe) is there an easy way to do this? [02:19:42 CET] <relaxed> Buliarous: I recommend mkvmerge for this: https://mkvtoolnix.download/doc/mkvmerge.html#mkvmerge.description.split [02:20:23 CET] <relaxed> if matroska is an ok output container [02:20:59 CET] <Buliarous> must be avi unfortunately ... but that is good to keep in mind for the future [02:23:29 CET] <relaxed> https://ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c… [02:25:49 CET] <k-man> hi [02:26:57 CET] <relaxed> Buliarous: might be easier to use mkvmerge and then remux to avi with ffmpeg [02:32:42 CET] <Buliarous> relaxed: thanks! i usually work with mkv so definitely will be keeping that in mind for later. I found this to work for my purposes: https://superuser.com/questions/712893/how-to-split-a-video-file-by-size-wi… The split-video.sh script works really well and you can do something like ./split-video.sh myMovie\ transcode.avi 120000000 "-vcodec copy -acodec copy" to split into pieces of [02:32:48 CET] <Buliarous> 120mb and keep the video and audio codecs, which is pretty great [02:34:10 CET] <relaxed> that looks pretty hacky [02:34:25 CET] <Buliarous> kudos to LukeLR whoever you are [02:41:27 CET] <Buliarous> relaxed: sure is [16:10:07 CET] <th3_v0ice> For UDP input, is FFmpeg automatically setting cicrular buffer or some other parameters? I am getting "Input/Output Error" while reading UDP with av_read_frame(). Circular buffer overflow is shown above it. [17:07:38 CET] <JEEB> th3_v0ice: that just sounds like you're running out of buffer because you're not processing stuff quickly enough [17:07:54 CET] <JEEB> if you need more buffer you can configure that [21:21:20 CET] <th3_v0ice> JEEB: Ok, thanks. Other things point out that that seems to be the case. [00:00:00 CET] --- Tue Nov 13 2018

1 0

ffmpeg-devel.log.20181111
by burek 12 Nov '18

12 Nov '18

[00:12:37 CET] <cone-517> ffmpeg 03Andreas Rheinhardt 07master:6dafcb6fdb62: h264_redundant_pps: Fix logging context [00:12:38 CET] <cone-517> ffmpeg 03Michael Niedermayer 07master:c305e134ce23: avcodec/imm4: Use ff_set_dimensions() [02:13:30 CET] <cone-517> ffmpeg 03Jun Zhao 07master:81f2a9f136ca: fftools/ffmpeg: Remove the micor like "#if 1" [02:13:31 CET] <cone-517> ffmpeg 03Jun Zhao 07master:3eccf5be9287: fftools/ffmpeg: Put the variable declaration at uppper for block. [02:13:32 CET] <cone-517> ffmpeg 03Jun Zhao 07master:e24a754916be: fftools/ffmpeg: Indent the code [12:23:06 CET] <BtbN> If I << a char, it will be auto promoted to an int, right? And not just shift out stuff after the first 8 bit? [12:28:34 CET] <atomnuker> I'd cast it to make it obvious and be on the safe side [12:45:55 CET] <thardin> I believe most/all artithmetic promote to at least int [12:46:16 CET] <thardin> being explicity might be nice tho [13:42:35 CET] <cone-542> ffmpeg 03Paul B Mahol 07master:8860d307311a: avfilter/vf_lut3d: ignore last whitespace when comparing LUT size string [13:53:23 CET] <durandal_1707> what about replacing locale dependent functions that we use with native variants? so . is always used and not ,? [13:59:33 CET] <atomnuker> yes, that would be awesome, lavu already replaces some so there can't be that many left [15:08:38 CET] <durandal_1707> sscanf is not trivial to do [15:12:22 CET] <atomnuker> yeah, seems so, wm4 wrote https://github.com/wm4/libinsanity and its strtod is complex and gplv3 [15:13:31 CET] <durandal_1707> that code is useless for us [15:16:13 CET] <atomnuker> yeah, but you could rewrite parts of it to use in sscanf [15:23:32 CET] <durandal_1707> atomnuker: why? i think about just using one of BSD implementations [15:26:00 CET] <iive> what the license of musl? [15:26:06 CET] <iive> what is... [15:26:21 CET] <durandal_1707> AGPL+ [15:28:00 CET] <durandal_1707> MIT actually [15:42:46 CET] <durandal_1707> are there other functions that handle . for floats differently? [15:46:16 CET] <durandal_1707> also should i add new header lavfu/avstdio.h or put it into lavu/avstring.h ? [15:49:42 CET] <durandal_1707> anyone dare to answer? [15:50:04 CET] <atomnuker> I think this belongs in avstring.h [15:50:07 CET] <BtbN> Can't ffmpeg just force the locale to C on startup or something? [15:50:21 CET] <atomnuker> libraries shouldn't mess with locales [15:50:38 CET] <BtbN> Was thinking more of the cli tool [15:50:58 CET] <atomnuker> also the c.utf8 locale isn't available everywhere [15:51:14 CET] <durandal_1707> its our mess, we need to fix it, and this is long issue [15:51:19 CET] <JEEB> mpv got some weird PR regarding that which doesn't build on windows [15:54:42 CET] <JEEB> durandal_1707: btw do you want to give any hints how a filter chain could be profiled? http://up-cat.net/p/e9f4a0cc [15:56:12 CET] <durandal_1707> JEEB: profiled for what kind of issues? [15:56:26 CET] <JEEB> blocking/slowness [16:03:11 CET] <durandal_1707> JEEB: you could try to insert graphmonitor filter to see if something queues to much frames, and to see what is outputing frames at least rate, you will need to change your graph, and add second video output which you could encode to and watch immediately in separate process (no pipe, as that would block others) [16:04:34 CET] <durandal_1707> do you work with files? [16:05:05 CET] <JEEB> generally live input, although you can always dump the input into a file if a reproducible thing is required [16:05:18 CET] <JEEB> although that might not repro it because the input can get new stuff right away [16:06:10 CET] <durandal_1707> if that bug happens after parameters change midstream that is currently not supported generally by lavfi [16:06:39 CET] <JEEB> I don't think that's the case [16:07:57 CET] <durandal_1707> then slowest encoder may slow others [16:11:36 CET] <JEEB> yea, I'll probably be able to give more info later next week, one of my hypotheses was that pre-framesync2 seemingly handled stuff better compared to the later versions. but I'll have to double-check that it isn't the sub2video patches I've posted on the ML fixing issues with overlays receiving premature EOS or ending up unscaled after a re-init [16:13:21 CET] <JEEB> although it seemed to be there even during the first sub2video fix version (which didn't hit the premature EOS root reason properly) [16:13:37 CET] <JEEB> and which went to master because it passed the single FATE test for it [16:13:59 CET] <JEEB> (did I mention how much I €!%!& sub2video?) [16:14:27 CET] <JEEB> it seems to be confusingly overcomplicated for a thing that's just supposed to provide overlay inputs [16:15:59 CET] <durandal_1707> sometimes filter my just hang for whatever reason, usually at eof [16:18:02 CET] <JEEB> well, EOF shouldn't be a problem. false EOS can happen with single filter chain and reconfig of say audio [16:18:38 CET] <JEEB> but false EOS generally just results in overlay's secondary input stopping, but output seems to work [16:18:46 CET] <JEEB> just that you stop getting subtitles overlayed [17:33:07 CET] <jkqxz> jamrial: Got a stream lying around with the alternative transfer characteristics message in? [17:35:54 CET] <jamrial> no, but koda probably does. he's the one that added support to the decoder [17:36:26 CET] <jamrial> you can look at it later in any case. no need to delay that patch just for it [17:36:49 CET] <jkqxz> I've already written it (took two minutes). Would be nice to test! [17:36:57 CET] <jamrial> ah :p [17:40:40 CET] <jkqxz> None of the conformance streams have it. [17:44:05 CET] <durandal_1707> atomnuker: see my quick & dirty hack skills on ML - comments welcome [17:46:34 CET] <durandal_1707> i copied parts of musl MIT code [17:47:23 CET] <jkqxz> FFFFFILE is a funny type name. [17:48:45 CET] <cone-542> ffmpeg 03Mark Thompson 07master:fd1d735c0b98: fate/libavcodec: Fix config dependency of h264-levels test [17:53:00 CET] <jamrial> jkqxz: it's a relatively recent addition for backwards compat. decoders compliant with and old spec will use the standard trc reported in the bitstream, new ones will look at the sei and use that instead [17:53:17 CET] <jamrial> probably to support hdr videos on old decoders or such [17:57:58 CET] <jamrial> jkqxz: x265 --atc-sei option generates one [17:58:17 CET] <jamrial> not ideal, i guess [18:00:21 CET] <jkqxz> I'm looking at some random HLG samples now. (<https://4kmedia.org/travelxp-4k-hdr-hlg-sample/> lacks the SEI message, but it does kill Intel GPUs with VAAPI. Oops.) [18:02:01 CET] <JEEB> the travelxp sample I think has general corruption issues [18:02:44 CET] <rcombs> jkqxz: have you seen dolby vision samples [18:03:56 CET] <rcombs> they went and made up a color space [18:03:57 CET] <jkqxz> Hmph. That actually seems to have messed the GPU up pretty badly; I probably need to reboot to get it back. [18:04:27 CET] <rcombs> wow [18:04:32 CET] <nevcairiel> doesnt DV use ICtCp? That was added to the standards some time ago [18:04:41 CET] <rcombs> nevcairiel: not quite [18:04:46 CET] <jkqxz> rcombs: Trying to avoid them. [18:04:50 CET] <rcombs> it's something like ICtCp but not quite [18:04:50 CET] <JEEB> nevcairiel: they adjust it. just adding base ICtCp support with BT.2020/PQ doesn't cut it [18:05:01 CET] <rcombs> here have some samples https://dl.dropboxusercontent.com/s/bsgtnhnix56zutb/Aerial-vid-URLs.rar [18:05:04 CET] <nevcairiel> of course DV is not PQ [18:05:15 CET] <rcombs> we're pretty sure it's PQ [18:05:22 CET] <JEEB> also we're specifically talking about profile 5 [18:05:28 CET] <JEEB> which is the backwards-incompatible one [18:05:44 CET] <JEEB> and which uses a bastardization of PQ+ICtCp etc [18:06:33 CET] <durandal_1707> what is that? [18:06:41 CET] <rcombs> happy fun times https://gist.github.com/a8c91d940d4291120bb677eafc96e41d [18:07:41 CET] <JEEB> ah, so that's the parser for the DOVIConfigurationBox [18:07:47 CET] <nevcairiel> (note that the first part of the commit is technically wrong, a decoder should be capable of unsetting those things) [18:08:23 CET] <rcombs> nevcairiel: I'm not sure if it should in the "the bitstream doesn't have those values at all" case, though [18:09:34 CET] <nevcairiel> where else, the decoder should keep the context up to date with what the bitstream says, and if it says unspecified, then it should set that [18:09:36 CET] <rcombs> I've also been looking into this mostly just out of curiosity; the only files I've seen using it are random online demos/trailers, and those apple Aerial screensavers I just linked [18:09:36 CET] Action: nevcairiel shrugs [18:10:20 CET] <rcombs> well if the decoder overwrites with "unspecified" after the container set something, that leaves the consumer with no way to find out what the container said [18:10:43 CET] <nevcairiel> or maybe there needs to be a proper api to separate that information [18:10:50 CET] <nevcairiel> what if the stream contains conflicting into [18:10:50 CET] <rcombs> maybe [18:10:54 CET] <nevcairiel> you still wont know [18:11:01 CET] <rcombs> fair point, and I think one of apple's streams actually does that [18:14:47 CET] <jkqxz> <https://4kmedia.org/lg-cymatic-jazz-hdr-hlg-uhd-4k-demo/> contains the message, but it also has broken AUDs so requires a bit of hacking to make CBS read it. [18:16:21 CET] <jamrial> i have the hdr10 version of that video, and it doesn't have the sei [18:17:14 CET] <jkqxz> HDR10 doesn't have the backward compatibility of HLG, so it would make less sense there. [18:19:09 CET] <jkqxz> <https://0x0.st/slfp.txt> [18:19:43 CET] <jkqxz> (With rbsp_stop_one_bit being zero in the AUDs. Yay.) [18:24:52 CET] <cone-542> ffmpeg 03Mark Thompson 07master:252e79663de8: cbs_h265: Add PTL parsing for sublayers [18:26:50 CET] <jamrial> extract_extradata should probably also extract prefix sei messages i guess [18:29:52 CET] <jkqxz> It only wants some message types, though. [18:30:42 CET] <jkqxz> And maybe not necessarily all of the time if they they change through the stream, which they could do independently of the parameter sets. [18:54:11 CET] <nevcairiel> SEI messages have a defined lifetime, those with the highest one might make sense to extract [19:17:12 CET] <durandal_1707> why: ffmpeg -i MUSIC_WITH_COVER -i ONLY_MUSIC -lavfi amix=inputs=2:duration=shortest -f null - stops when first video frame is encoded? [20:24:37 CET] <cone-542> ffmpeg 03Andreas Rheinhardt 07master:6df9020f45ea: cbs_mpeg2: Improve performance of writing slices [20:28:53 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/1c915dfc426512288559cd8f18cba382ec… [20:29:00 CET] <philipl> Common CHECK_CU implementation. [20:35:53 CET] <cone-542> ffmpeg 03Marton Balint 07master:6c2a7a8e9a36: avfilter/vf_framerate: factorize SAD functions which compute SAD for a whole frame [20:35:54 CET] <cone-542> ffmpeg 03Marton Balint 07master:7748f395de88: avfilter/vf_select: use common scene sad functions [20:35:55 CET] <cone-542> ffmpeg 03Marton Balint 07master:936d18fb42bb: avfilter/vf_minterpolate: use common scene sad functions [20:39:15 CET] <nevcairiel> philipl: public api for that makes me feel bad [20:47:48 CET] <philipl> nevcairiel: alternative? [20:50:21 CET] <jkqxz> nevcairiel: +1 [20:50:36 CET] <jkqxz> philipl: Include it in each library separately? [20:51:30 CET] <philipl> Ok. It seems we need three copies. That's still less than eight I guess. [20:54:10 CET] <philipl> Is there a legal way to share a single .c file between the various libs? [20:55:42 CET] <jkqxz> #include [20:56:23 CET] <philipl> I mean file placement... [20:56:32 CET] <philipl> Do we do this anywhere today? [20:56:47 CET] <wbs> there's a few cases, look at the various log2_tab.c [20:56:52 CET] <JEEB> :) [21:01:27 CET] <jamrial> avpriv? [21:01:46 CET] <jamrial> also, what wbs said works as well [21:07:38 CET] <cone-542> ffmpeg 03Martin Vignali 07master:0aba92d42d51: avcodec : add prores_metadata bsf for set the color property of each prores frame [21:07:39 CET] <cone-542> ffmpeg 03Martin Vignali 07master:679ad3146972: fate/prores_metadata_bsf : add test for setting color property [21:15:03 CET] <philipl> avpriv just means I change the prefix? [21:15:09 CET] <philipl> That seems the easy option [21:21:50 CET] <wbs> the problem with that is that even though it's supposed to be private, for shared libraries it more or less ends up as something that needs to be kept stable anyway, depending on how flexible linking setups you want to consider [21:22:51 CET] <philipl> This would be stable in practice. We just don't want it to be part of the public API, right? [21:24:04 CET] <philipl> But Ok, I see how I can reproduce what is done for log2_tab.c [21:26:22 CET] <wbs> log2_tab.c is fine as long as the amount of data/code is small so adding a few bytes per library is easier than handling the symbol across dynamic linking boundaries (even though iirc such things should work fine even for msvc setups now) [21:26:54 CET] <philipl> It's a single small function. [21:37:40 CET] <cone-542> ffmpeg 03Paul B Mahol 07master:bdc66c50dd69: avfilter/af_afftfilt: extend filter functionality [21:37:41 CET] <cone-542> ffmpeg 03Paul B Mahol 07master:d03030c07109: avfilter/af_afftfilt: add more window types [21:44:26 CET] <cone-542> ffmpeg 03Martin Vignali 07master:752bf1f64c4c: fate/prores_metadata : fix md5 value [21:44:35 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/be8f30cc355d553003d0cb9772f872d752… [21:44:46 CET] <philipl> and everyone else who had opinions :-) [21:45:12 CET] <BtbN> looks sensible to me on first glance [22:13:49 CET] <JEEB> > Let me add that split filter derived sources seems to be also single threaded. [22:14:00 CET] <JEEB> hmm, I wonder if that's correct [22:22:03 CET] <durandal_1707> it is not correct for asplit and audio, same for video (didn't tested video) [22:33:35 CET] <durandal_1707> but after split, slowest one will slow all others after split [23:43:51 CET] <rcombs> nevcairiel: so apparently tls_schannel hard-fails if the OCSP service is down [23:43:54 CET] <rcombs> any idea how to not [23:44:21 CET] <rcombs> fails in InitializeSecurityContext [23:51:23 CET] <nevcairiel> no clue [00:00:00 CET] --- Mon Nov 12 2018

1 0

ffmpeg.log.20181111
by burek 12 Nov '18

12 Nov '18

[14:39:26 CET] <tombb> Hi All, can ffmpeg do LKFS? I need to convert a file and normalize the audio to -24db LKFS... is that possible? [14:41:19 CET] <JEEB> "Loudness units relative to full scale is a synonym for LKFS that was introduced in EBU R128." [14:41:37 CET] <JEEB> so I would guess an audio normalization filter applying EBU R128 should be good enough? [14:41:55 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#loudnorm [14:42:00 CET] <JEEB> see this filter's documentation [14:45:00 CET] <tombb> oh! lufs == lkfs then? [14:45:05 CET] <tombb> cool - thank you! [14:46:10 CET] <JEEB> it seems so at least according to a random quote from wikipedia [14:46:19 CET] <JEEB> given that broadcast went for the EBU R128 spec [14:46:28 CET] <JEEB> I would expect there to be relevant parameters :P [14:54:26 CET] <tombb> stupid EBU :P - thanks! [15:39:57 CET] <tombb> what would be the right way to combine filter_complex and loudnorm? I would like to split one stereo stream to 2 monos (pan=1c|c0=c0[left];[0:1]pan=1c|c0=c1[right]) and also control their loudness [15:41:19 CET] <tombb> (the stereo to mono part works fine, but I can't add filter_complex and loudnorm in the same command) [15:41:47 CET] <durandal_1707> pan=1c|c0=c0,loudnorm=....[left];[0:1]pan=1c|c0=c1,loudnorm=.....[right] [15:42:23 CET] <furq> -lavfi channelsplit[a0][a1];[a0]loudnorm=xyz[out0];[a1]loudnorm=xyz[out1] [15:57:06 CET] <tombb> awesome! thank you guys [22:51:19 CET] <hololeap> i'm trying to broadcast a file to the network with RTP, like so: ffmpeg -i example.mp3 rtp://10.0.0.255 [22:51:51 CET] <hololeap> but i get an error: [22:51:51 CET] <hololeap> [NULL @ 0x564dac4314d0] Unable to find a suitable output format for 'rtp://10.0.0.255' [22:51:51 CET] <hololeap> rtp://10.0.0.255: Invalid argument [22:53:28 CET] <JEEB> you need to select a muxer [22:53:34 CET] <JEEB> since there's no extension or anything for RTP [22:55:09 CET] <hololeap> is there a passthrough-style muxer? i don't need to re-encode it, just broadcast it [22:56:04 CET] <JEEB> those are separate [22:56:11 CET] <JEEB> -c copy is for copying AVPackets from input to output [22:56:18 CET] <JEEB> -f XXX is for the container format [22:59:15 CET] <hololeap> [rtp @ 0x55f4c8500a20] Data doesn't look like RTP packets, make sure the RTP muxer is used [22:59:22 CET] <hololeap> what is the flag for setting the muxer? [22:59:47 CET] <JEEB> -f XXX [23:00:29 CET] <JEEB> there's at least two muxers that have rtp in their name [23:00:32 CET] <JEEB> rtp and rtp_mpegts [23:04:20 CET] <hololeap> yeah, i'm not sure what's going wrong: https://paste.pound-python.org/show/98jf0P6eAPjDVnNf8AEe/ [23:05:45 CET] <JEEB> well for one thing you've forgotten the "please do not re-encode this" switch [23:05:51 CET] <JEEB> which I mentioned earlier [23:06:35 CET] <JEEB> the rest I don't know but you might also need -re before -i INPUT to simulate reading the input with a specific speed [23:06:45 CET] <JEEB> which basically sleeps between reads :P [23:06:53 CET] <hololeap> right... and i figured out the other part. it was apparently trying to use a <1024 port as non-root. it seems to be working now. [23:13:05 CET] <hololeap> is there a way to slow down the transcoding so that it outputs at 1:1 speed in relation to the length of the file? it seems to be trying to output as fast as possible [23:13:38 CET] <JEEB> I mentioned an option for the sleep()s ;P [23:13:55 CET] <hololeap> oh, sorry :) [23:18:14 CET] <hololeap> it's working great, thanks JEEB ... except that it is broadcasting to the address i specified over the wrong interface. it is using lo... you wouldn't happen to know how to change that, would you? [23:19:12 CET] <JEEB> I would looke at hte AVOptions for the rtp protocol [23:19:44 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#rtp [23:19:51 CET] <JEEB> there's probably a way to get it through teh command line as well [23:20:57 CET] <hololeap> hmm... yeah i don't see anything that talks about the interface unfortunately [23:21:31 CET] <hololeap> i might be able to work around it with iptables [23:21:55 CET] <JEEB> yea, the UDP protocol had an option -localaddr [23:22:06 CET] <JEEB> which let you force the interface with a specific address [23:22:18 CET] <JEEB> (it was useful with multicast if your routes were incorrectly set for receiving) [23:23:40 CET] <JEEB> I think the RTP protocol underneath uses the UDP protocol but to be honest I've not looked into RTP in lavf enough :P [23:26:54 CET] <hololeap> i tried rtp://10.0.0.100:5000?localaddr=10.0.0.104, but it didn't make a difference [23:27:37 CET] <JEEB> yea because the rtp thing doesn't take that thing in and you have to separately pass things through :P [23:27:46 CET] <JEEB> within lavf [23:28:17 CET] <JEEB> and tbh I didn't check enough of the code to see if the UDP code is actually using stuff from udp.c [00:00:00 CET] --- Mon Nov 12 2018

1 0

ffmpeg-devel.log.20181110
by burek 11 Nov '18

11 Nov '18

[02:02:31 CET] <philipl> BtbN: https://github.com/philipl/nv-codec-headers/commit/7b88dd0250e3cc8055e9e639… [02:02:56 CET] <BtbN> So it was the syncornization after all? [02:03:27 CET] <philipl> No [02:03:38 CET] <philipl> But I got synchronization working and that will be necessary [02:04:09 CET] <philipl> It's not really possible to do a pool strategy with images like I did with the buffer implementation [02:04:26 CET] <philipl> so I need synchronization to make sure we don't copy the next frame until the previous one has been read out of the image. [02:04:46 CET] <BtbN> I'll have a look tomorrow, way too late right now [02:04:52 CET] <philipl> Sure. I'm surprised you're up [02:05:51 CET] <BtbN> Well, there was a certain chess match. [02:06:04 CET] <BtbN> That ended up taking almost 8 hours. [02:47:52 CET] <cone-221> ffmpeg 03James Zern 07master:6d3890ee34fd: libvpxenc,vp9: add enable-tpl option [02:59:13 CET] <cone-221> ffmpeg 03James Zern 07master:55e021f39b02: libvpxenc: extend auto-alt-ref range [10:53:12 CET] <BtbN> philipl, lgtm. I'll wait a bit until doing another round of releases, in case something else comes up, which has happened surprisingly frequently lately. [16:46:39 CET] <philipl> BtbN: thanks. Would you take the change with the kernel launch API stuff? It's not actually very much. [16:47:46 CET] <philipl> https://github.com/philipl/nv-codec-headers/commit/692ef24e3242286a0b6bfa4d… [16:47:49 CET] <philipl> for reference [16:49:25 CET] <BtbN> Well, it won't make it non non-free [16:49:47 CET] <philipl> I know. [16:50:04 CET] <philipl> But it at least scopes the problem to the ptx compilation [16:53:36 CET] <BtbN> hm, I guess it also makes the binary at least runable without the nvidia driver installed, which might be a plus to some internal deployments. [16:58:13 CET] <philipl> Yeah [17:07:56 CET] <BtbN> Go ahead then [17:26:17 CET] <philipl> Ok. I'll push these but I won't tag for release. Yeah? [17:55:33 CET] <philipl> BtbN: https://opensource.stackexchange.com/questions/4304/redistributing-lgpl-2-1… [17:55:43 CET] <philipl> not much clarity [17:56:54 CET] <BtbN> Reads pretty clear to me [17:57:09 CET] <BtbN> Unless we get it to compile and work with clang, it's non-free. [17:57:18 CET] <philipl> I investigated that. [17:58:17 CET] <BtbN> I wonder how things would look if the ptx would be commited. But I doubt that'd be accepted. [17:58:40 CET] <philipl> There are missing language features, and, I think, the thing that sinks the whole ship, is that you end up linking in a copy of cudart to provide the cuda api implementations. [17:58:51 CET] <philipl> It's not like there's a libc equivalent handing out on the GPU side. [17:59:37 CET] <philipl> The other thing I was wondering about was what if the ptx was loaded as a separate file off the filesystem. That means you can rebuild the lgpl part any time you want however you want. and the ptx runs on the card (so separate address space, etc) [18:00:00 CET] <philipl> Arguably, the ptx being inside the library is aggregation and not linking. [18:00:10 CET] <philipl> but it makese the replacement requirement much harder [18:01:10 CET] <philipl> So you could say "Here is ffmpeg". "If you download this ptx and place it in the right place, the filter works" [18:02:35 CET] <BtbN> I don't think there is much arguing here. It's just non-free [18:02:46 CET] <philipl> But there's an important point there. [18:03:01 CET] <philipl> If you do what I just said what about the ffmpeg build is non-free if the ptx isn't in there? [18:03:22 CET] <philipl> The argument then is that the ptx is non-free and how do you get that [18:03:29 CET] <BtbN> It seems like cheap trickery to me [18:03:51 CET] <BtbN> But you'll have to discuss that with an fsf lawyer [18:04:18 CET] <philipl> It's not cheap. If you say the ptx is non-free and non-redistributable, the functionality is just as unavailable as it was before. [18:05:10 CET] <philipl> I don't have have any commerical motivtions behind any of this; I'm just interested in maximising availability to end users. [18:05:33 CET] <BtbN> I'm not against that at all, but that solution seems as anti-end-user as it gets. [18:05:56 CET] <BtbN> (And would also be an API break) [18:06:26 CET] <philipl> Sure. [18:06:31 CET] <philipl> I suspect this is all futile anyway. [18:06:52 CET] <philipl> It's really the proprietary compiler question. Everything else is rearranging deck chairs on the titanic. [18:16:07 CET] <cone-517> ffmpeg 03bnnm 07master:27e114b4511b: avcodec/wmaprodec: improve XMA missing samples [18:18:19 CET] <uau> hevc frameskip still seems broken (https://github.com/mpv-player/mpv/issues/6218) there's also a patch from Mark Wu on the mailing list without replies (from 2018-10-23) [18:18:37 CET] <uau> could someone fix/apply that? [18:20:14 CET] <philipl> BtbN: And now the pix fmt question. The easy/lazy thing is to punt on pix fmts for now and just do 444p16. Otherwise it's organising a vote?!? [18:20:33 CET] <BtbN> Seems like it. [18:21:56 CET] <philipl> Even though I'm in favour of the new pix fmts, I'd feel better if I could find some discussion of the industry position on this (like there is for P010). But I can't find any. [18:23:24 CET] <philipl> We know the nvdec docs won't help - they only talk about P016 today and so I'm sure they'll just say 444p16 when they are updated. [18:29:56 CET] <jamrial> uau: you don't have push access to the repo? [18:32:06 CET] <uau> no [18:32:50 CET] <jamrial> ok, will push in a bit [18:38:12 CET] <cone-517> ffmpeg 03Mark Wu 07master:10bc4c3a7df7: avcodec/hevcdec: fix non-ref frame judgement [19:05:48 CET] <j-b> 'morning [19:14:19 CET] <durandal_1707> do you type in every channel that? [19:33:00 CET] <atomnuker> its 18:00, its not even morning [19:33:28 CET] <durandal_1707> he sleep too much [19:33:37 CET] <atomnuker> worse, imagine if it was morning, then you'd be reminded its morning [19:36:05 CET] <BradleyS> good morning :) [19:36:33 CET] <cone-517> ffmpeg 03Mark Wu 07release/4.0:263b3ad40749: avcodec/hevcdec: fix non-ref frame judgement [19:36:35 CET] <cone-517> ffmpeg 03Mark Wu 07release/4.1:11dff170ef79: avcodec/hevcdec: fix non-ref frame judgement [19:47:22 CET] <durandal_1707> michaelni: when you will resign as leader for real? [19:54:24 CET] <jamrial> durandal_1707: do something else if you're bored instead of stirring shit, please [19:55:42 CET] <kierank> durandal_1707: why you troll michael [20:18:06 CET] <durandal_1707> kierank: because he is still leader [20:18:18 CET] <kierank> i don't disagree but why raise it now? [20:21:09 CET] <durandal_1707> he is blocking CoC [20:22:22 CET] <kierank> not the only one [20:22:32 CET] <kierank> you got to follow vote process or whatever "rules" exist [20:24:01 CET] <durandal_1707> kierank: no, we must use force now! [20:24:15 CET] <kierank> should have said that at vdd [20:26:28 CET] <BBB> yeah, we had this discussion at VDD [20:26:33 CET] <BBB> I told all you guys to be there [20:26:37 CET] <BBB> you werent there [20:26:38 CET] <BBB> sorry [20:26:50 CET] <BBB> I believe thilo said he would move it forward [20:27:07 CET] <durandal_1707> jamrial: i got impression, that you are not very fond of me? [20:27:34 CET] <BBB> I think jamrial wishes you could be more positive [20:27:40 CET] <BBB> but I wont put words in his mouth [20:27:51 CET] <jamrial> durandal_1707: i am fond of you, but you really seem to like to troll people when things are quiet [20:41:27 CET] <durandal_1707> kierank: ok, i gonna do Carl statue then [20:43:44 CET] <kierank> durandal_1707: you can buy bricks from elon musk boring company [20:51:33 CET] <durandal_1707> kierank: i thought to make it from space frozen trash [22:16:42 CET] <cone-517> ffmpeg 03Paul B Mahol 07master:0bc2326b90a7: avfilter/vf_lut3d: add cosine 1D interpolation [22:16:43 CET] <cone-517> ffmpeg 03Paul B Mahol 07master:c47b48c0a629: avfilter/vf_lut3d: add spline 1D interpolation [22:22:46 CET] <durandal_1707> 9 more commits [00:00:00 CET] --- Sun Nov 11 2018

1 0

ffmpeg.log.20181110
by burek 11 Nov '18

11 Nov '18

[04:44:30 CET] <`St0ner> how do i report the bug i mentioned above regarding converting OPUS audio inside a WEBM file directly to ALAC? it does not provide an MD5 match with the original audio and results in a file that is triple the size of the equivalent WAV, so i have to convert to WAV first, and then convert WAV to ALAC [04:46:02 CET] <Pocari> I'm still not sure that's because of some bug in ffmpeg [04:46:34 CET] <Pocari> when you tried to play that malformed ALAC, did it work= [04:46:36 CET] <Pocari> ?* [05:12:12 CET] <`St0ner> will remake and check [05:14:10 CET] <Pocari> k [11:52:00 CET] <roger21> hi there [11:52:35 CET] <roger21> is it possible to convert idx/sub files into str? [11:55:17 CET] <roger21> i tried "ffmpeg -i a.idx -c:s srt a.srt" doesn't work [12:21:14 CET] <ariyasu> you need to ocr them roger21 [15:39:09 CET] <hwdyki> i'm building 4.1 from source with the following opts: --target-os=linux --enable-gpl --enable-version3 --enable-nonfree --enable-shared --disable-w32threads --enable-bzlib --enable-libfontconfig --enable-libfreetype --enable-libmp3lame --enable-libspeex --enable-libtheora --enable-libvorbis --enable-openssl --enable-libx264 --enable-zlib --disable-x86asm --disable-random [15:39:43 CET] <durandal_1707> --disable-x86asm --> VERY BAD IDEA [15:40:23 CET] <furq> i don't know what disable-w32threads or disable-random are doing there [15:40:36 CET] <hwdyki> and i'm getting Unknown input format: 'concat' when running ffmpeg -f concat -i chunks -c copy FILE [15:41:00 CET] <hwdyki> do i need any ext libs for concat? [15:41:01 CET] <furq> well yeah disable-random randomly disables components [15:41:28 CET] <hwdyki> hmm. [15:43:10 CET] <durandal_1707> hwdyki: from where you got source? [15:45:11 CET] <furq> https://www.johnvansickle.com/ffmpeg/ [15:45:16 CET] <furq> you might just want to use the builds from here [15:45:38 CET] <hwdyki> ffmpeg.org [15:47:49 CET] <durandal_1707> hwdyki: than make sure you use right ffmpeg version and not some prahistoric one in path [15:48:11 CET] <furq> well also don't use an option that randomly disables stuff [15:48:41 CET] <hwdyki> 4.1 is prahistoric? [15:49:33 CET] <relaxed> you could have an older version in your $PATH [15:49:51 CET] <hwdyki> nope. [15:51:47 CET] <durandal_1707> pastebin full uncut ffmpeg console output [15:52:19 CET] <furq> uh [15:55:51 CET] <hwdyki> took out --disable-random, still the same. [15:57:12 CET] <relaxed> what does this return? ffmpeg -formats 2>&1|grep concat [15:58:22 CET] <hwdyki> nvm fixed it. [16:11:35 CET] <dariken> nice, 4.1, no builds yet. av1 encoding on acceptable speeds now? [16:11:56 CET] <JEEB> that's up to libaom or rav1e [16:12:14 CET] <JEEB> although I don't think rav1e has a c api yet [23:01:41 CET] <zinger> I'm trying to devoces some ALAC files to WAV. The ALAC files are 24-bit but FFmpeg makes the into 16-bit WAV files. How do I tell FFmpeg not to downgrade the files from 24-bit to 16-bit? [23:01:53 CET] <zinger> devoces->decode [23:05:28 CET] <Pocari_> zinger, try ffmpeg -i in.m4a -af aformat=s24:44100 out.wav [23:05:46 CET] <relaxed> zinger: try -c:a pcm_s24le -f wav output.wav [23:06:33 CET] <Pocari_> zinger, that's assuming your sample rate is 44100 Hz, if not change it to whatever it is [23:07:56 CET] <zinger> isn't there a setting that just tells FFmpeg to use the same settings as the source file? [23:09:34 CET] <relaxed> zinger: the default codec for wav is pcm_s16le, changing it to -c:a pcm_s24le should keep it lossless [23:10:20 CET] <Pocari_> does that also copy over the sampling rate (not just the word length) losslessly? [23:11:58 CET] <relaxed> encode both to pcm and hash them to see if it's still lossless [23:12:10 CET] <Pocari_> yeah, I was also going to suggest md5 too [23:13:40 CET] <zinger> for some reason FFmpeg kept the original 88,2 kHz when it downgraded the ALAC from 24-bit to 16-bit [23:14:28 CET] <Pocari_> ok, now md5 hash both the ALAC and the WAV to see if it's genuinely lossless [23:14:28 CET] <relaxed> he tries to maintain as much as possible [23:24:53 CET] <zinger> thanks for the help guys! :-) [23:32:50 CET] <rom1v> hi [23:33:37 CET] <rom1v> in doc/APIchanges: "2016-04-11 - 6f69f7a / 9200514 - lavf 57.33.100 / 57.5.0 - avformat.h " [23:33:59 CET] <rom1v> how I am supposed to test it properly using LIBAVCODEC_VERSION_INT, since there are 2 versions? [23:47:23 CET] <rom1v> maybe #if (LIBAVFORMAT_VERSION_MICRO == 100 && LIBAVFORMAT_VERSION_INT >= AV_VERSION_INT(57, 33, 100)) || LIBAVFORMAT_VERSION_INT >= AV_VERSION_INT(57, 5, 0) [23:47:49 CET] <rom1v> missing: && LIBAVFORMAT_VERSION_MICRO == 100 [23:47:52 CET] <rom1v> == [23:47:54 CET] <rom1v> 0 [00:00:00 CET] --- Sun Nov 11 2018

1 0