Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

July 2019

1 participants
38 discussions

ffmpeg-devel.log.20190712
by burek 13 Jul '19

13 Jul '19

[08:56:54 CEST] <JEEB> did lavf have a "no AVPackets in X time" sort of thing yet? [08:57:24 CEST] <JEEB> I only remember rw_timeout which is general I/O [09:00:37 CEST] <Compn> you mean a message or a feature that waits for input ? [09:03:18 CEST] <JEEB> means to detect "technically the input is alive, but we couldn't parse anything useful from it in X time". although I'm also not sure if this should be in the API client or in the API :) [09:03:54 CEST] <JEEB> think of an MPEG-TS input that is still sending in the index, but suddenly no data for any of the PIDs, for example [09:44:31 CEST] <CyberShadow> Hi [09:44:31 CEST] <CyberShadow> durandal_1707 Compn: Yes though the user I created it for has since submitted a few examples where the filter wasn't working as well at it could. I had some ideas for how to improve it (make it localized) but ran out of time and got swamped with other projects. [10:06:39 CEST] <kierank> JEEB: the demux would have to know about time [10:06:42 CEST] <kierank> which afaik it doesn't [10:11:38 CEST] <JEEB> or the general lavf packet reading loop, yup [10:11:46 CEST] <JEEB> (the one within lavf) [10:11:54 CEST] <JEEB> but yes, most likely not a thing atm [11:32:22 CEST] <durandal_1707> I NOW HATE ALL ABOUT MULTIMEDIA! [11:47:42 CEST] <J_Darnley> The only good thing about it is the waifus [11:47:51 CEST] <JEEB> :D [11:47:52 CEST] <J_Darnley> If you don't like them then I see your point [11:49:41 CEST] <kierank> durandal_1707: why [11:56:25 CEST] <durandal_1707> kierank: leechers everywhere! [12:05:52 CEST] <kierank> durandal_1707: welcome to open source and the free rider problem [13:14:11 CEST] <pross> Compn: \O/ [15:00:52 CEST] <durandal_1707> mkver: is there fate code that tests webm_chunk? [15:02:18 CEST] <mkver> Not that I am aware of. I think I ran fate at the time and if I did, it did pass (otherwise I would have not sent this patch). [15:19:38 CEST] <cone-410> ffmpeg 03Andreas Rheinhardt 07master:8c6ee7626bcc: lavf/webm_chunk: Fix NULL dereference [15:19:39 CEST] <cone-410> ffmpeg 03Andreas Rheinhardt 07master:24a64e0462d5: lavf/webm_chunk: Correct duration if start time > 0 [16:27:56 CEST] <Lynne> that svt review is savage [16:30:02 CEST] <durandal_1707> why? [16:31:14 CEST] <Lynne> "an embarrassment" [16:39:24 CEST] <nevcairiel> its not savage if the authors of the project themself say that it just wasnt ready to be published [16:39:40 CEST] <BBB> to his defense, he's saying his team's work is embarassing him [16:39:42 CEST] <BBB> I think it's ok [16:40:02 CEST] <BBB> he's basically saying "please don't review our/my work yet", which is saving us time, not savaging an external contributor [16:40:07 CEST] <J_Darnley> It is strongly worded but doesn't seem bad [16:40:23 CEST] <BBB> not very PC, I agree with that [16:40:28 CEST] <kierank> wow [16:40:41 CEST] <J_Darnley> Certainly not the worst stuff said in an FFmpeg channel [16:57:43 CEST] <durandal_1707> why patchwork does not automatically mark pushed patches? [16:59:08 CEST] <jamrial> "which is to get read and judged by all the experts on FFmpeg community" [16:59:13 CEST] <jamrial> we have seen worse :p [17:01:05 CEST] <durandal_1707> mkver: could you list links to patchwork of your matroskadec patches? [17:02:20 CEST] <durandal_1707> yo' bro' hav' se'n n'th'ng [17:03:14 CEST] <mkver> It's patches 17-37 of the matroskadec patches here: https://patchwork.ffmpeg.org/project/ffmpeg/list/?submitter=798 [17:03:47 CEST] <mkver> I dpn't know why the state of the already merged ones is still "new". [17:04:28 CEST] <jamrial> mkver: patchwork looks for keywords in replies to change the status of patches [17:04:41 CEST] <jamrial> i probably didn't use the correct keywords, or didn't reply to each patch [17:05:25 CEST] <jamrial> when that happens they need to be changed manually [17:07:35 CEST] <durandal_1707> mkver: but you have new patch, redo leven handling [17:09:21 CEST] <mkver> If you mean by this that this patch does not apply 100% cleanly any more, but needs a three-way-merge, then that's because of eb33be188d2acb99e8f0f6a5cb45c931ed947cd0. [17:09:33 CEST] <jamrial> durandal_1707: that's patch 23 updated after a change in a previous patch generated conflicts [17:11:40 CEST] <durandal_1707> we should switch to github PR [17:12:04 CEST] <mkver> Why? [17:12:28 CEST] <durandal_1707> easier to apply multiple patches in a row [17:12:29 CEST] <JEEB> durandal_1707: for us more likely would be videolan's gitlab [17:13:21 CEST] <jamrial> i would be fine with that [17:22:26 CEST] <mkver> Who's actually in charge of patchwork? I have already tried to register myself there, but some error (I don't remember which one) appeared and now my email and my preferred name is already taken, but when I try to login, I get a "This account is inactive" message. (When I use a different password, I get an incorrect password error, so I really remember my chosen password.) [17:24:02 CEST] <kierank> durandal_1707: nice troll [17:44:19 CEST] <durandal_1707> mkver: perhaps you need to activate it somehow? [17:46:05 CEST] <durandal_1707> kierank: you are jealous [17:46:19 CEST] <kierank> durandal_1707: why, I use github myself [17:47:40 CEST] <mkver> durandal_1707: If only I knew how... [18:06:46 CEST] <Lynne> google seem to have abandoned webm, no av1 spec [18:07:32 CEST] <JEEB> I think they only utilized webm where they didn't specify mp4 mappings first [18:07:43 CEST] <JEEB> as soon as you get mp4 you get DRM support etc [18:09:29 CEST] <Lynne> I'm glad annexb av1 hasn't caught on though [18:14:22 CEST] <jamrial> Lynne: webm av1 mapping is the same as matroska [18:15:23 CEST] <jamrial> which is based on the mp4 one. so av1C in codecprivate, no temporal delimiter obus in block data, etc [18:15:52 CEST] <jamrial> but yes, google moved to mp4. they also seemingly abandoned webp [18:16:34 CEST] <J_Darnley> They couldn't get anyone to adopt it meaning no Embrace, Extend, Extinguish [18:16:52 CEST] <Lynne> its not officially supported though, or at least the website hasn't been updated [18:18:08 CEST] <jamrial> libaom generates webms using the matroska spec, so it's official enough :p [18:19:12 CEST] <jamrial> J_Darnley: Windows 10 v1903 and Firefox both added support for webp [18:20:04 CEST] <J_Darnley> maybe so but did they convince anyone else to embrace it? users/creators in particular? [18:20:25 CEST] <J_Darnley> Google might have the direction of the "Embrace" action backwards. [18:20:30 CEST] <Lynne> nope, youtube only [18:20:50 CEST] <jamrial> some content providers did [18:21:09 CEST] <jamrial> serving webp if supported instead of jpg/png [18:21:32 CEST] <jamrial> saved them some bandwidth, but pissed off users when they couldn't do anything with the images they saved from the page :p [18:22:11 CEST] <J_Darnley> Unintentional DRM? Excellent [18:22:12 CEST] <Lynne> also probably bought the 50% size savings from google and starve the images [18:27:02 CEST] <J_Darnley> I wonder if I can blame a combination of that and idiot mobile users for all the low quality images I see [18:37:00 CEST] <Lynne> I wonder if you can somehow match up something written in the av1 spec with the avif spec such that insane tiling would be contradictory and unsupported [19:30:04 CEST] <durandal_1707> war of intel clones [21:32:24 CEST] <cone-624> ffmpeg 03Marton Balint 07master:397abca001c8: avformat/movenc: use unspecified language by default [21:32:24 CEST] <cone-624> ffmpeg 03Marton Balint 07master:81d3d7dd44ac: avformat/mpegts: respect program number when merging streams [22:56:55 CEST] <Compn> durandal_1707, "<CyberShadow> durandal_1707 Compn: Yes though the user I created it for has since submitted a few examples where the filter wasn't working as well at it could. I had some ideas for how to improve it (make it localized) but ran out of time and got swamped with other projects." [23:27:53 CEST] <Compn> doh\ [23:28:13 CEST] <Compn> michaelni, you can test the photosensitive filter, the results are visually easy to spot [23:29:55 CEST] <Compn> to answer a question no one asked, there is no exact known flashing light frequency that causes a seizure. filtered sunlight is commonly used i believe. there have been some experiments with 120hz vs 50hz flashing lights but it has not been studied [23:30:13 CEST] <Compn> mostly because its not morally great to test seizures on people. [23:58:45 CEST] <Compn> michaelni, a good test for the photosensitive filter would be to see if it visually distorts when it shouldnt. e.g. run it on known clips to see how badly it affects them [00:00:00 CEST] --- Sat Jul 13 2019

1 0

ffmpeg.log.20190712
by burek 13 Jul '19

13 Jul '19

[00:00:12 CEST] <JEEB> that will give you like 90% of all decoders and other stuff like that [00:00:23 CEST] <JEEB> you will get a nice list of enabled modules at the end of configure [00:00:28 CEST] <JEEB> when it finishes configuring your build [00:02:20 CEST] <steve___> This is an Abbott and Costello routine, except it's not funny (although it's getting close) [00:04:02 CEST] <Thomas_J> You are right. What I am doing now is using a list of directives that I went through a week ago on things that I may possibly need in the future so I would not have to go through this again. There are a couple of thiings that I have already extablished that I need. [00:04:23 CEST] <JEEB> aom? on an rpi3? [00:04:37 CEST] <kepstin> speed measured in frames per week, lol :) [00:04:39 CEST] <JEEB> you are not going to be decoding or encoding AV1 on your rpi [00:04:58 CEST] <JEEB> and aom is not going to be in your repos [00:05:55 CEST] <Thomas_J> I have already streamed a video to Facebook without glitches from my rpi. [00:06:47 CEST] <kepstin> if you use the hardware encoder, that's quite reasonable do to. with appropriate settings, you can probably even manage x264 with sufficiently fast settings. [00:06:52 CEST] <kepstin> not possible with av1. [00:07:13 CEST] <JEEB> stream copy will also work fine, too [00:07:19 CEST] <Thomas_J> And as I say, if things seem to bog down once I get the whole thing running, I will move it to a Rock Pi 4B [00:07:53 CEST] <JEEB> ok, if you really want all that enabled, feel free [00:09:45 CEST] <Thomas_J> No, you are right. I will flush out all that is not needed to do rtsp in, alsa in, needed filtering, and gnutls [00:10:27 CEST] <Thomas_J> I am troubleshootng things that I don't even need. [00:11:57 CEST] <Thomas_J> Should I build static? [00:15:14 CEST] <kepstin> no point if you're running on the same box you're building on, it can make things more complex [00:15:30 CEST] <kepstin> just use the defaults (don't specify any related ffmpeg configure options) [00:19:58 CEST] <JEEB> static is default anyways [00:20:50 CEST] <DHE> static means one of two things: the libraries are built as .a files instead of .so files - I like this best, but doesn't do well when building intermediary libraries using ffmpeg. or static means the executable is static, which is a tougher undertaking. [00:20:55 CEST] <DHE> --enable-static means the former [00:25:17 CEST] <Thomas_J> I've stripped the directives down to nill but pkg-config isn't finding anything. [00:25:40 CEST] <Thomas_J> It now can't find libtls. [00:31:38 CEST] <Thomas_J> What does "pkg-config --exists --print-errors libtls" mean? Everything that can't be found has print-errors??? [00:32:44 CEST] <JEEB> libtls != gnutls [00:35:23 CEST] <Thomas_J> They are all starting to blend together in my eyes. I have l--enable libtls followed by --enable-gnutls. Duhh [00:56:00 CEST] <Thomas_J> make is running right now and it is taking forever. I am going to dinner. So thanks all for your help. Tomorrow, I will be working with a brand new build. [02:35:45 CEST] <BenMcLean> Hey guys. I need some help. I'm trying to make a simple Windows batch file which will edit the metadata in a video file designating that it is a 3D SBS video for purposes of YouTube and stereoscopic 3D VR video players that support it [02:36:09 CEST] <BenMcLean> Now its my understanding that if you just want to edit metadata, then you shouldn't need to re-encode, it should just be an immediate change [02:36:30 CEST] <BenMcLean> but when I run my command, it seems to be re-encoding anyway [02:36:46 CEST] <BenMcLean> here is the command: ffmpeg -i %1 -c:v copy -c:a copy -c:s copy -c:d copy -c:t copy -metadata:s:v:0 stereo_mode=1 "%~n13D.%~x1" [02:37:18 CEST] <BenMcLean> that should just copy everything, not re-encode right? [02:37:41 CEST] <BenMcLean> the idea is to put that in a batch file, and then drag+drop the video file onto the batch file [02:38:28 CEST] <BenMcLean> Is my idea sound in principle? or am I just way off base here about how any of this works? [02:39:01 CEST] <BenMcLean> i know it has the right input file name and output file name at least [02:40:31 CEST] <BenMcLean> oh wait, no it wasn't quite right. need to remove the extra dot at the end [02:42:08 CEST] <BenMcLean> oh I think the correct command was ffmpeg -i %1 -metadata:s:v:0 stereo_mode=1 -codec copy "%~n13D%~x1" [02:43:18 CEST] <MarkB2> I'm looking for a tool that will allow me to find rectangle size and top-left corner of an image so that (sorry) I can stop guessing with ffmpeg's crop option. [02:44:19 CEST] <MarkB2> Might anyone have seen such a thing? [02:53:53 CEST] <MarkB2> Ah. Thank you. Good idea. [02:53:56 CEST] <MarkB2> Cheers. [02:59:00 CEST] <nine_milli> blb_ [03:12:29 CEST] <tesseractcat> Hello, let's say I have a few hundred thousand image (PNG) files representing frames for a video. What's the fastest way to convert it to a video (i don't care about format as long as it's fast) [03:22:33 CEST] <DHE> depending on the filenames.... ffmpeg -f image2 -pattern_type glob -i "*.png" -c libx264 -preset faster -crf 23 output.mp4 [03:22:52 CEST] <DHE> assuming "*.png" naturally orders the images correctly [03:23:12 CEST] <tesseractcat> filenames are like output_%04d [03:23:33 CEST] <DHE> that should be fine... [03:23:39 CEST] <DHE> make sure to put quotes around "*.png" [03:23:46 CEST] <tesseractcat> ok [03:23:49 CEST] <tesseractcat> what does crf 23 do [03:24:07 CEST] <DHE> H264 quality parameter. lower numbers are higher quality but bigger filesize [03:24:15 CEST] <DHE> 23 seems to be a good sweet spot to start with. tune up/down as needed [03:24:27 CEST] <tesseractcat> i see [03:24:36 CEST] <tesseractcat> thanks [03:25:21 CEST] <DHE> you said speed matters. "faster" can also become "veryfast" or "superfast" if speed really really matters, but encoding quality deteriorates. [03:27:00 CEST] <tesseractcat> yeah, most i could get with šffmpeg -framerate 24 -i output_%04d.png -c:v libx264 out.mkvš was about 0.2-0.3x speed [10:22:05 CEST] <Adcock> what is resolution? [10:22:32 CEST] <Adcock> Compare 1366x768 vs 1080o [10:22:40 CEST] <Adcock> I am not trolling. [10:22:51 CEST] <Adcock> I don't understand the difference. [10:22:54 CEST] <Adcock> :( [10:50:50 CEST] <mixfix41> i thought you could play a file while capture x11?? [10:51:57 CEST] <mixfix41> i guess maybe some cases but i probs dont want to either since could record the audio of the launch video [10:53:49 CEST] <mixfix41> with similar to ffmpeg -f x11grab -i :0.0 -i default -preset ultrafast -crf 18 -pix_fmt yuv420p file.mkv [10:54:45 CEST] <mixfix41> though needd framerate + vid size in there [10:58:21 CEST] <mixfix41> i like how ffmpeg puts the audio in convenient [10:58:27 CEST] <mixfix41> oh thats pulse i guess [20:58:37 CEST] <Thomas_J> Hi... [21:02:45 CEST] <whitestone> does someone manage streamlink and live video in youtube? [21:02:53 CEST] <whitestone> i have questions to do [21:03:09 CEST] <whitestone> youtube change something about two days [21:03:23 CEST] <whitestone> youtube-dl cant get anymore the m3u8 links [21:04:36 CEST] <Thomas_J> I have an rtsp: IP camera with h264/720p output streaming to Facebook with a separate audio channel for external audio. I am using -c:v copy and ffmpeg decided that it will use 480p for output. Shouldn't it be outputing 720p? [21:05:11 CEST] <whitestone> put the command [21:05:37 CEST] <whitestone> no but it dont work in that way [21:05:48 CEST] <whitestone> do you have youtube-dl in your machine [21:06:09 CEST] <whitestone> this is a live transmission, i am dealing with that right now [21:06:41 CEST] <whitestone> Thomas_j:send yhose commands, youtube-dl -F youtube link [21:06:54 CEST] <whitestone> it will appear a list of possibilitties there [21:07:19 CEST] <whitestone> Thomas_j, do you have the link? [21:07:33 CEST] <Thomas_J> I am streaming to Facebook using rtmps. Not the same. [21:07:39 CEST] <whitestone> or, can you share the link with us? [21:08:05 CEST] <whitestone> i was thinking it was youtube [21:08:18 CEST] <whitestone> never streamed for facebook [21:08:40 CEST] <whitestone> you can use streamlink, it shows the option to download the video [21:09:32 CEST] <Thomas_J> I'm sorry. I wasn't tying to answer you but ask a separate question. I am using ffmpeg to stream rtmps directly to Facebook. [21:10:02 CEST] <Thomas_J> I am setting up Live streaming. [21:10:36 CEST] <kepstin> whitestone: if youtube-dl stopped working, then you should check their github - they update fairly rapidly, and there might already be an issue open for the problem explaining what changed. [21:10:41 CEST] <whitestone> i am trying to help you usle [21:10:44 CEST] <whitestone> https://github.com/streamlink/streamlink/blob/master/src/streamlink/plugins… [21:10:59 CEST] <whitestone> check there, streamlink has a plugin [21:11:10 CEST] <Thomas_J> As I say, I am not dealing with Youtube. [21:11:31 CEST] <kepstin> Thomas_J: you need to share your comple ffmpeg output so we can read it and then tell you which part of the output explains why you're getting 480p [21:11:47 CEST] <whitestone> i dont know if ffmpeg works with facebook, streamlink has a plugin and is supposed it works [21:12:07 CEST] <whitestone> kepstin, i already say to share the link [21:12:13 CEST] <whitestone> sory, not the link [21:12:15 CEST] <whitestone> the commands [21:12:22 CEST] <Thomas_J> If I wanted a 3rd party to stream through, I have my own dedicated server on line running nginx. But nginx doesn't do rtmps out. [21:12:55 CEST] <kepstin> whitestone: Thomas_J is not trying to *play* a facebook stream, he has a completely different issue [21:12:56 CEST] <whitestone> ok, if you dont share the command is difficult to help you [21:13:12 CEST] <kepstin> Thomas_J: please ignore whitestone's stuff about youtube-dl, and just share your ffmpeg command *and complete output* [21:13:13 CEST] <whitestone> he want to save it, isnt it? [21:13:35 CEST] <Thomas_J> I have a full stream running live now. (with several weeks working on getting the right build.) [21:13:37 CEST] <whitestone> and i told him to share the command [21:14:23 CEST] <whitestone> ok, someone know how to get a mpd link to download dash videos from youtube? [21:14:24 CEST] <pink_mist> whitestone: you're completely wrong on all counts [21:14:33 CEST] <Thomas_J> That's okay, Yesterday, I was having a hard time to following what everyone was saying. [21:14:47 CEST] <kepstin> whitestone: contact youtube-dl developers on their github. it might be that you just need a new version [21:15:23 CEST] <kepstin> whitestone: they fix that kind of thing pretty quick - if it's not already fixed, check for or open an issue [21:19:45 CEST] <Thomas_J> As I say, I have finally got a stream to Facebook working incorporating an external audio source. The way it's working is because I pulled all the strenuous commands out of the command string and just doing a -c:v copy. [21:21:10 CEST] <Thomas_J> Problem now is that ffmpeg is not using the camera's input video size. [21:21:22 CEST] <whitestone> i tested and is not working, i am asking here because there are many users and people with a lot of knowledge [21:21:43 CEST] <whitestone> i was using ffmpeg with HLS and works grear [21:22:08 CEST] <whitestone> but right now i dont know how to get the links to provide them to FFMPEG [21:22:34 CEST] <whitestone> does someone know how to get links to let FFMPEG to download videos? [21:23:32 CEST] <Thomas_J> Are you using rtsp: for an input stream? [21:26:37 CEST] <Thomas_J> Sorry. I reread tour earlier text-lines. Good luck with that. [21:30:58 CEST] <pink_mist> whitestone: mpv has a lua script that grabs links from youtube-dl and then hands them to ffmpeg to download https://github.com/mpv-player/mpv/blob/master/player/lua/ytdl_hook.lua .. if that doesn't help you, I don't know [21:36:24 CEST] <Thomas_J> Incredible! My live stream is taking in and decoding 720p h264 with a separate audio input channel. It is re-encoding and streaming out rtmps to Facebook and all inside a Raspberry PI3 B+. I have had no drops, video stuttering or errors in over an hour. [21:37:43 CEST] <Thomas_J> It looks like the RPi3b is going to work. [21:38:23 CEST] <pink_mist> is it really re-encoding? thought you said you used -c:v copy [21:39:54 CEST] <Thomas_J> The fact that it is re-encoding with the wrong 640p instead of 720p, I think it is. [21:41:29 CEST] <pink_mist> oh, uh, well ok then :P [21:46:04 CEST] <kepstin> if you used -c:v copy, then it is not re-encoding, therefore it is not changing resolution [21:46:46 CEST] <kepstin> so either your camera is providing a different resolution than you think it is, or facebook is re-encoding it. If you share the ffmpeg output like I asked you do to, I could have told you which. [21:47:16 CEST] <pink_mist> he already left [21:47:27 CEST] <pink_mist> well, ping timeouted [21:47:27 CEST] <kepstin> ah, nice [22:22:06 CEST] <Thomas_J> The output of my IP camera has about a 3 to 4 second delay. I need to set a delay in the audio input channel to sync it. [22:23:34 CEST] <yaymukund> hello, i am trimming and cropping some video and would like to just test it very quickly. I need the timing to be precise, but don't care about quality at all. What's the best encoding strategy? [22:23:56 CEST] <yaymukund> I'm doing ultrafast -crf 0 [22:24:39 CEST] <yaymukund> (Would shrinking the video help any?) [22:26:35 CEST] <yaymukund> hmm, maybe I shouldn't be using libx264. Sorry for the long question. [22:26:46 CEST] <Thomas_J> I'm trying to think of what I can use to put in front of the camera with audio and it is not a copyrighted source to sync up the audio with the camera. [22:28:16 CEST] <furq> yaymukund: -f nut -c:v rawvideo - | mpv - [22:29:54 CEST] <yaymukund> ooo, interesting. for what it's worth I'm extracting many different sectons of a long video and joining them so I don't think I can simply pipe. [22:30:03 CEST] <yaymukund> But that looks promising. I shall read more! [22:30:16 CEST] <furq> well yeah nothing is quicker than rawvideo if you have the disk space [22:30:32 CEST] <yaymukund> I do! [22:36:47 CEST] <yaymukund> ooh, I could do filter_complex to get all the subsections in a single giant command [22:54:28 CEST] <kepstin> yaymukund: note that x264 is probably faster with crf != 0, since (at least with 8-bit) 0 sets lossless mode [22:54:40 CEST] <kepstin> although ymmv [22:57:10 CEST] <kepstin> in some cases, resizing the video smaller using a low-quality resize method can speed things up. (with the default resize method, it can also slow things down) [22:57:10 CEST] <linext> anyone watch season 2 of one punch man? [00:00:00 CEST] --- Sat Jul 13 2019

1 0

ffmpeg-devel.log.20190711
by burek 12 Jul '19

12 Jul '19

[00:42:36 CEST] <tmm1> does the vaapi encoding api make it simple/possible to inject sei like a53cc? [00:44:57 CEST] <nevcairiel> the vaapi encoding api has you assemble the bitstream yourself [00:45:14 CEST] <nevcairiel> so adding SEI is relatively easy if you already do all that work anyway [00:45:27 CEST] <philipl> Bonus! [06:26:30 CEST] <cone-133> ffmpeg 03Steven Liu 07master:092bd1e54fef: avcodec/videotoolboxenc: remove unused variable [06:26:30 CEST] <cone-133> ffmpeg 03Steven Liu 07master:1498e3943920: avutil/hwcontext_vaapi: move kernel_driver into CONFIG_LIBDRM [06:26:30 CEST] <cone-133> ffmpeg 03Steven Liu 07master:1b1b974aace7: avformat/http: change error message from numeric code to string [06:26:30 CEST] <cone-133> ffmpeg 03Steven Liu 07master:89ea0c9bfdab: fate: add hls_init_time option fate [06:26:30 CEST] <cone-133> ffmpeg 03Steven Liu 07master:33a8cd5925a0: avformat/hlsenc: use one handler for m3u8 and segments [06:26:31 CEST] <cone-133> ffmpeg 03Steven Liu 07master:af9dc02e6b07: fate: add hls_list_size fate test case [14:36:01 CEST] <dastan> hello people [14:36:25 CEST] <dastan> does someone know how to get a MPD link from youtube video? [14:37:36 CEST] <dastan> i am working to process youtube video throw ffmpeg, and all my system was working in HLS but yesterday i saw that youtube change the live transmissions to DASH protocol [14:39:17 CEST] <J_Darnley> I don't know. Try youtube-dl, maybe [14:41:17 CEST] <dastan> youtube-dl works fine giving me the HLS links, but not with dash [14:41:40 CEST] <JEEB> please ask youtube-dl support then [14:41:43 CEST] <J_Darnley> See if it has an option to give you this other thing [15:16:07 CEST] <nevcairiel> youtube doesnt actually use dash that often anymore [15:16:22 CEST] <kurosu> dastan: you've been asking for the past few days user questions, that belong to #ffmpeg. Could you ask them in #ffmpeg ? [15:17:34 CEST] <dastan> i do, sorry [15:18:49 CEST] <dastan> but sometimes the answers to questions like, does ffmpeg supprt dash with mpd links? are from the developpers [15:19:03 CEST] <dastan> but sorry for today [15:20:55 CEST] <kurosu> dastan: no, still user questions even if devs can be interested. This channel is about developing ffmpeg or libav* libs, not using or developing with. Says so in the channel topic [15:21:21 CEST] <kurosu> Easier for people like me that have to quickly comb through the channel log [15:26:52 CEST] <dastan> ok [15:32:37 CEST] <Lynne> nevcairiel: they no longer do anything above low bitrate 720p h264 as non-dash [15:35:02 CEST] <dastan> i dont know, my project is about live tranmission [15:56:07 CEST] <thebombzen> it appears that matroska files muxed with mkvmerge pretty consistently produce this error in the matroska demuxer [15:56:10 CEST] <thebombzen> [matroska,webm @ 0x55f302ca6140] Element at 0x1babba9b ending at 0x1babc008 exceeds containing master element ending at 0x1babba95 [15:57:00 CEST] <thebombzen> this is because mkvmerge adds the duration of the last frame [15:57:12 CEST] <thebombzen> is this a violation of the matroska spec in mkvmerge, or a bug in ffmpeg? [15:58:10 CEST] <thebombzen> cause either way, files freshly produced by mkvmerge shouldn't immediately spit out an error message in ffmpeg's demuxer. it's gotta be a bug in one of those two [16:06:31 CEST] <mkver> It's a bug in our matroska demuxer. Your analysis is wrong; see here: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244193.html for why it happens. [16:10:34 CEST] <kierank> durandal_1707: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-July/246446.html [16:10:38 CEST] <kierank> INCEPTION [16:10:42 CEST] <kierank> fuzzer finds bug in fuzzer [16:14:58 CEST] <nevcairiel> Lynne: i suppose it depends how you define dash, you can get progressive http streams of the video and audio data just fine for many files, they may put a dash manifest on top of that to have browsers manage it, but alas for many players its easier to just take those two streams as-is [16:27:59 CEST] <durandal_1707> kierank: indeed, this is serious, is ffmpeg even real? [16:28:21 CEST] <kierank> durandal_1707: my leader thinks we are in a simulation [16:28:49 CEST] <durandal_1707> elon? i do not take him seriously. [16:33:52 CEST] <durandal_1707> come on!, apply those matroska patches for once, will you ? [16:39:00 CEST] <kierank> durandal_1707: yes, landing rockets and electric cars are fake [16:39:00 CEST] <kierank> duh [16:40:19 CEST] <durandal_1707> space is fake [16:44:24 CEST] <kierank> ah ok [16:44:26 CEST] <kierank> explains a lot [16:54:34 CEST] <gnafu> If we're all living in a simulation, does that mean the outside world is even worse and /this/ is considered an improvement? [16:54:51 CEST] <gnafu> Like, this is a VR game everyone uses to escape the woes of their existence? [16:55:37 CEST] <J_Darnley> When you die in the game you "wake up" in real lift? [16:55:49 CEST] <J_Darnley> Only to discover there is no heaven, only hell? [16:56:13 CEST] <cone-194> ffmpeg 03Paul B Mahol 07master:2601eef850f1: avcodec/magicyuv: add support for recently added YUV444P10 [17:02:02 CEST] <gnafu> J_Darnley: But then are you given the option to go back in as a new character? Or are we characters, and when we die it's just the end of our code? [17:03:04 CEST] <J_Darnley> If you believe in re-incarnation then that is a sign that you bought the respawn expansion pack [17:11:26 CEST] <durandal_1707> bought with what? [17:20:40 CEST] <gnafu> durandal_1707: Probably some BS coins you got in-game that wealthier players just buy. [17:21:08 CEST] <durandal_1707> aha, block-chain coins [18:15:03 CEST] <kierank> karma [19:55:25 CEST] <dastan> hi people [19:55:51 CEST] <dastan> i want to let you know ffmpeg is not working with dash links in youtube live channels [19:56:21 CEST] <dastan> is there one of the developpers right now? [19:56:42 CEST] <durandal_1707> nope, devs are starving [20:00:08 CEST] <kierank> dastan: open trac ticket [20:00:13 CEST] <kierank> this is not place for bug reports [20:00:17 CEST] <kierank> this is dev chat [20:00:50 CEST] <dastan> kierank, i am new [20:01:12 CEST] <dastan> sorry for the troubles [20:01:18 CEST] <kierank> every day you come to channel and spam issue offtopic [20:01:25 CEST] <dastan> i know there is a place to put that [20:01:38 CEST] <dastan> but is interesting to talk with the devs time to time [20:01:43 CEST] <nevcairiel> bug reports go on trac, general chat goes in #ffmpeg, if you want to actually work yourself on fixing it, then you can talk about it here [20:02:10 CEST] <dastan> everyday? i enter to the irc about three days ago [20:02:19 CEST] <dastan> you know me about one year? [20:03:15 CEST] <kierank> 19:02:11 <dastan> everyday? i enter to the irc about three days ago [20:03:19 CEST] <kierank> by definition that's every day [20:04:42 CEST] <dastan> thats your definition of every day [20:04:45 CEST] <dastan> i am new [20:05:18 CEST] <dastan> so if you want you can bother someone else [20:05:30 CEST] <dastan> i understand that i am doing something wrong [20:06:00 CEST] <dastan> sorry for spam your precious irc [20:06:26 CEST] <durandal_1707> this is call center, we wait for questions from users all the time [20:07:02 CEST] <dastan> call center? [20:09:53 CEST] <dastan> go and bother someone else ok, thanks for being nice [20:11:31 CEST] <durandal_1707> we are ffmpeg gods, you can not treat us like that! [20:14:49 CEST] <dastan> hey, i am very grateful about the work that you do with ffmpeg [20:15:18 CEST] <dastan> i am making a project based on your system, but i am a technician, i am studing development at this moment [20:15:46 CEST] <dastan> i really like to help if i can, but i cant [20:16:55 CEST] <kierank> ask in #ffmpeg [20:18:05 CEST] <jamrial> durandal_1707: don't be an asshole [20:19:03 CEST] <durandal_1707> jamrial: or what? [20:19:18 CEST] <JEEB> way to go with that reaction [20:19:30 CEST] <jamrial> or nothing. just don't troll people with random nonsense [20:20:11 CEST] <jamrial> if you can't, or wont aid someone asking for help, then just don't talk to them [20:51:23 CEST] <BBB> dastan: I Think you misunderstand the goal of this channel; we try to help other/fellow ffmpeg devs work on (not with) ffmpeg. by expanding the scope of this channel to helping other/fellow devs work with (no on) ffmpeg, some devs will lose interest and will go away and no longer be on this irc channel. therefore, such questions should go elsewhere so the original scope of this irc channel can be maintained [20:51:43 CEST] <BBB> dastan: questions of fellow ffmpeg devs working on (not with) ffmpeg go here; questions of fellow ffmpeg devs working with (not on) ffmpeg go in #ffmpeg [20:52:16 CEST] <BBB> dastan: the same scope difference applies to mailinglists also (ffmpeg-devel@ for on-ffmpeg dev, libav-devel@ for api questions, ffmpeg-user@ for user questions) [20:52:56 CEST] <BBB> the separation isn't for users; it's for devs. some devs don't want to help users, but we still want these devs to stick around and remain interested [21:47:07 CEST] <dastan> jamrial, thanks for your support [22:02:24 CEST] <kurosu> BBB: he's been told this 3 times now [22:02:53 CEST] <kurosu> I can put him on ignore if all active devs here are ok with his behaviour [22:02:58 CEST] <BBB> I am not [22:03:31 CEST] <kurosu> (still, I'm on #ffmpeg, but rarely comment) [22:05:30 CEST] <BBB> I'm not on #ffmpeg for this very reason ;) [22:11:28 CEST] <durandal_1707> :( [22:17:49 CEST] <Lynne> why are all emails from china in the future? [22:18:13 CEST] <JEEB> something is handling time zones incorrectly or? [22:18:21 CEST] <JEEB> because china is pretty far time zone wise [22:19:30 CEST] <kurosu> because huawei is now futurewei [22:53:44 CEST] <durandal_1707> Compn: are you real old Compn? [22:54:28 CEST] <Compn> i dont have my freenode password at the moment, but yes, still in the middle of a move across country [22:54:31 CEST] <Compn> what up durandal_1707 [22:55:23 CEST] <durandal_1707> nothing, was just curious [22:56:08 CEST] <Compn> durandal_1707, i forgot, do you work on video filters? need someone to review / make patch and submit to mailing list the bright flash filter [22:56:19 CEST] <Compn> i asked michaelni but didnt get any reply via email [22:57:04 CEST] <durandal_1707> Compn: i think OP lost interest after nobody came with actual real feedback [22:57:05 CEST] <Compn> http://trac.ffmpeg.org/ticket/2104 [22:57:29 CEST] <Compn> thats fine his filter works good enough as is [22:58:09 CEST] <durandal_1707> you tested it with real people? [22:58:43 CEST] <durandal_1707> or you get headache with flashing lights after some time :) ? [22:59:01 CEST] <JEEB> btw, do I remember correctly that we export the DRC information from certain formats for downmix? [22:59:23 CEST] <nevcairiel> that is correct [23:01:35 CEST] <JEEB> do we actually utilize that anywhere, or is the API user left to read that info from a structure and then pass it onto swresample/lavfi? [23:04:56 CEST] <nevcairiel> its side data i believe, not sure we have anything that actually uses it [23:07:09 CEST] <Compn> durandal_1707, i tested the clips i have (which are on my other computer, i will upload when i get access to it again) [23:08:15 CEST] <Compn> durandal_1707, it will get real testing after it is introduced into the wild. i approve of it anyway [23:08:31 CEST] <Compn> visually. i did not review code (it needs code review) [23:08:49 CEST] <durandal_1707> Compn: code is mostly fine [23:16:52 CEST] <michaelni> Compn, oops, i rememberf seeing the mail, i then wanted to look but totally forgot [23:18:06 CEST] <Compn> no problem michaelni :) [23:18:47 CEST] <michaelni> well, its a problem for anyone who would have benefited from the filter :( [23:19:42 CEST] <durandal_1707> there is even paper that specifies how filter should operate in some detail [23:20:01 CEST] <Compn> photosensitive epilepsy [23:20:09 CEST] <Compn> not really this is new tech durandal_1707 [23:21:07 CEST] <JEEB> hmm, I think .jp TV broadcasters have filters for that since the pokemon incident in I think... '98? [23:27:48 CEST] <Compn> could you do some japanese googling for it ? [23:28:00 CEST] <durandal_1707> CyberShadow: you are author of this filter? [23:33:17 CEST] <Compn> i think so yes [23:40:58 CEST] <Compn> https://onlinelibrary.wiley.com/doi/pdf/10.1046/j.1440-1819.2000.00770.x [23:41:22 CEST] <Compn> https://www.epilepsy.com/connect/forums/products-resources-helpful-links/co… [23:43:49 CEST] <durandal_1707> there was paper that strictly followed patented algorithm [23:44:02 CEST] <durandal_1707> not that it is important for us [23:49:22 CEST] <JEEB> michaelni: bc1749c6e46099ec85110361dbe6f7994a63040d seems to cherry-pick -x cleanly at least up to 2.8, so which releases should it be back-ported to? [23:54:17 CEST] <Compn> https://journals.lww.com/neurotodayonline/Fulltext/2005/03000/Lessons_From_… [23:54:23 CEST] <michaelni> JEEB, all up to 2.8 seems a good choice then [23:55:37 CEST] <JEEB> ok, I will then go wash myself and do a build loop of them [23:56:07 CEST] <JEEB> although the primary thing that seems to be utilizing whatever causes a re-negotiation seems to mostly be facebook for one reason or another :) [00:00:00 CEST] --- Fri Jul 12 2019

1 0

ffmpeg.log.20190711
by burek 12 Jul '19

12 Jul '19

[00:31:40 CEST] <Thomas_J> Can anyone point me to the latest master git source for download? I am afraid that the packages on the downloads page have the rtmps fix migrated into them yet. [00:33:14 CEST] <another> https://ffmpeg.org/download.html#get-sources [00:37:10 CEST] <Thomas_J> Are these the master git packages? [00:37:21 CEST] <another> i guess you could try removing pulse but i'm not sure [00:39:24 CEST] <another> not sure what you mean [00:40:15 CEST] <klaxa> just run git pull https://git.ffmpeg.org/ffmpeg.git [00:40:27 CEST] <another> it's the source [00:40:33 CEST] <another> klaxa: clone [00:40:39 CEST] <klaxa> right [00:40:43 CEST] <klaxa> git clone [00:41:01 CEST] <klaxa> he wanted the latest master git source? [00:41:03 CEST] <klaxa> that's it [00:41:48 CEST] <Thomas_J> The reason I ask is that the rtmps bug is recently fixed but it hasn't trickled down yet. I spent 2 days banging my head against a wall trying to get an rtmps stream going to facebook and found that the prebuilt bin's rtmps was broken in it. [00:42:22 CEST] <klaxa> yeah sounds like something you'd want git master for, "just" get the source and compile it [00:42:29 CEST] <klaxa> there's guides for that too if you run into problems [00:45:10 CEST] <Thomas_J> The prebuild that I'm running now successfully streams to facebook but I need to recompile it to get audio input support working. [00:46:39 CEST] <Thomas_J> I need to add a separate audio source to the stream but this build can't find the supporting alsa modules. [00:50:29 CEST] <nine_milli_> i never seen a wyatt who wasnt a computer programmer [00:51:00 CEST] <Thomas_J> how about Wyatt Earp [00:51:17 CEST] <nine_milli_> dunno who that is [00:51:27 CEST] <Thomas_J> He was a trouble shooter. [00:51:37 CEST] <another> i don't think the build is your problem but rather your system [00:51:56 CEST] <Thomas_J> Brave courageous and bold? [00:53:15 CEST] <Thomas_J> I've reinstalled libasound2 twice and it still did not produce the /usr/lib/alsa-lib subdirectory for support modules. [00:53:29 CEST] <another> yes [00:53:32 CEST] <steve___> maybe keep reinstalling it and see [00:55:04 CEST] <Thomas_J> Steve; That was sarcasm wasn't it. right? [00:55:41 CEST] <another> i once again recommend reading which is an underrated skill [00:55:55 CEST] <another> anyway, i'm out [00:56:18 CEST] <Thomas_J> Only a fool does the same thing over and over again expecting a different result each time. [00:57:08 CEST] <Thomas_J> Thqanks for your help. I ahve been reading for 2 months and my eyes are giving out. [00:57:19 CEST] <another> ... [00:57:20 CEST] <another> https://en.wikipedia.org/wiki/Hermeneutic_circle [00:59:22 CEST] <Thomas_J> In other words, don't take things out of context like politicians do. [01:01:06 CEST] <Thomas_J> That's a huge package. I only have 7% so far. I'm going to dinner. [01:01:21 CEST] <another> that's.... absolutly not what the hermeneutic circle is about [01:02:14 CEST] <Thomas_J> That's what I get out of it but that's my interpretation. [01:02:21 CEST] <steve___> haha [01:03:50 CEST] <Thomas_J> I'm gone to dinner, By Y'all. [01:08:40 CEST] <steve___> bye [08:06:08 CEST] <lain98> how do i check if a video has vfr through the libraries ? [08:50:40 CEST] <nine_milli> blb_ [11:44:44 CEST] <sine0> anyone know of a channel for media editing [15:27:44 CEST] <dastan> does someone know how to get the MPD links from youtube? [15:33:59 CEST] <thebombzen> dastan: youtube-dl [15:35:11 CEST] <dastan> how? [15:35:25 CEST] <dastan> because i know how to get the HLS link [15:36:41 CEST] <dastan> but i am searching about youtube-dl and mpd links and i dont find nothhing [15:54:54 CEST] <thebombzen> dastan: O I thought you meant HLS links, my bad [15:55:02 CEST] <thebombzen> try asking in #youtube-dl and see if it's possible [17:35:12 CEST] <Thomas_J> Hello? Can you hear me now? [17:57:04 CEST] <Hello71> no [17:57:47 CEST] <Thomas_J> Finally got alsa working for input.(I think) But now i am getting Segmentation fault. This is the last line out following "Opening an input file: plughw:CARD=Device,DEV=0" [18:40:26 CEST] <ossifrage> Is there any way to get ffmpeg to compute frame durations for rtsp streams so it won't complain about "pkt->duration = 0, maybe the hls segment duration will not precise" [19:34:37 CEST] <dastan> hello [19:35:06 CEST] <dastan> does someone how to get the mpd root from a youtube channel to put into ffmpeg? [19:35:35 CEST] <dastan> i get this [19:35:42 CEST] <dastan> from youtube-dl [19:35:43 CEST] <furq> youtube-dl -g [19:35:45 CEST] <dastan> tecnico@MSS-ONE:~$ youtube-dl -F https://www.youtube.com/watch?v=MUvxW9uuzog [youtube] MUvxW9uuzog: Downloading webpage [19:35:46 CEST] <dastan> audio only DASH audio 144k , m4a_dash container, mp4a.40.2@128k [19:35:49 CEST] <dastan> , avc1.4d401f, 30fps, video only [19:36:25 CEST] <dastan> furq, with this option i get this [19:36:26 CEST] <dastan> https://r5---sn-p5qlsnz6.googlevideo.com/videoplayback?expire=1562888162&ei… [19:36:27 CEST] <dastan> =yes&mt=1562866485&fvip=5&keepalive=yes&c=WEB&sparams=expire%2Cei%2Cip%2Cid%2Caitags%2Csource%2Crequiressl%2Clive%2Chang%2Cnoclen%2Cmime%2Cgir&sig=ALgxI2wwRgIhAKUKSAz00atFRkBqHs-v8hOjXLGaQJ4VHkSO_LUseINfAiEAjMxmAuhtnbA6aD0Sr6FPSC5vQ2kw9q003yC8K96Pt_Q%3D&lsparams=mm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=AHylml4wRgIhANaji50OIxAhNqvadZiXaf-hUBQ [19:36:27 CEST] <dastan> LeA0noOJ-RaSLWj7_AiEAhkRDgG-oiVg5_8tnuIELVmc0_J4FfpdJnN2SP0q_mSA%3D&ratebypass=yes [19:36:37 CEST] <dastan> and is not working [19:37:01 CEST] <dastan> this way works fine for me with HLS, but not with dash [19:37:17 CEST] <furq> that works fine here [19:37:30 CEST] <furq> you need to quote it or your shell will interpret the &s [19:38:39 CEST] <dastan> ffmpeg -f dash -i "https://r5---sn-p5qlsnz6.googlevideo.com/videoplayback?expire=1562887842&ei… [19:38:39 CEST] <dastan> =video%2Fmp4&gir=yes&mt=1562866162&fvip=5&keepalive=yes&c=WEB&sparams=expire%2Cei%2Cip%2Cid%2Caitags%2Csource%2Crequiressl%2Clive%2Chang%2Cnoclen%2Cmime%2Cgir&sig=ALgxI2wwRQIhANt6Jnyzo1D-748zpIGSb-2uX-Q1sfFI50_TMIMcWAeDAiAFjVleIkYr0yOfCkgf6rAEEWXdppFlKVKxd2tb3e6fXg%3D%3D&lsparams=mm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=AHylml4wRAIgZ6krsxZY3 [19:38:40 CEST] <dastan> JoR5VYHiGbUmjMix7a64onZb4dtziQ43yQCIClWVy7MRKGJcyYtMg8W8gGpXhLer__QZi3sehzsqgnK&ratebypass=yes" -vcodec libx264 -preset ultrafast -f hls decklin.m3u8 [19:39:01 CEST] <dastan> i already put quotesw [19:39:14 CEST] <dastan> i put ffmpeg -f dash -i "" [19:39:56 CEST] <furq> get rid of -f dash [19:39:56 CEST] <dastan> its giving me a ·missing root node· [19:40:15 CEST] <furq> also don't paste 900 character urls into the channel [19:40:24 CEST] <dastan> sory [19:40:51 CEST] <dastan> i dont have access to pastebin to my company [19:41:40 CEST] <furq> http://vpaste.net/ [19:41:47 CEST] <furq> or any of the thousands of other pastebins [19:41:55 CEST] <dastan> ok, thanks menç [19:41:57 CEST] <kepstin> there's lots of pastebin sites on different urls, they can't all be blocked [19:41:58 CEST] <dastan> that works here [19:45:17 CEST] <dastan> with single quotes like '' it gives me the error http://vpaste.net/WcU0z#uploads?ft=a2ps [19:45:50 CEST] <dastan> with double quotes gives me this [19:46:28 CEST] <dastan> http://vpaste.net/hjqSk#uploads?ft=a2ps [19:48:25 CEST] <dastan> when you put the link generated by youtube-dl -g ffmpeg supposed to download all the videos of the repository, isnt it? [19:49:00 CEST] <furq> no -g will give you the urls that it got from auto format selection [19:49:05 CEST] <furq> you can use -g and -f together [19:49:25 CEST] <furq> with that said i get the same errors with that channel so either it's generally broken for live streams or there's an issue with this stream [19:50:15 CEST] <dastan> is what i do, first i use -F to get all the options [19:50:41 CEST] <dastan> the i make youtube-dl -f 136 -g youtube-link to get the link [19:51:11 CEST] <furq> you'd want -f 136+140 [19:51:19 CEST] <furq> then use both urls [19:51:23 CEST] <furq> that also doesn't work though [19:51:32 CEST] <dastan> yes, then i can map one over the other to get video and audio [19:51:37 CEST] <furq> https://clbin.com/gc5M2 [19:52:49 CEST] <dastan> this paste you send is full of errors [19:52:52 CEST] <furq> right [19:52:56 CEST] <furq> like i said it doesn't work [19:53:14 CEST] <furq> the same thing works fine for normal videos so i guess something is broken in live stream handling [19:53:22 CEST] <dastan> aaaaaa....i was thinking you said that was working in your chase [19:53:54 CEST] <dastan> fucking youtube, they change everything yesterday [19:54:50 CEST] <dastan> thay was working with HLS and was great for my project.....it was working, but right now, they change for dash video.....and everything is wrong.... [19:55:02 CEST] <dastan> can you check with other channel? [19:55:07 CEST] <furq> i'm doing that now [19:55:09 CEST] <dastan> i will check too [20:00:12 CEST] <dastan> it works with al jeazhera [20:00:21 CEST] <dastan> but it download only one segment [20:00:31 CEST] <dastan> how do you do to download all segments? [20:00:55 CEST] <furq> i think i'm getting ratelimited by youtube or something [20:01:02 CEST] <furq> trying youtube-dl -o - | ffmpeg -i - [20:01:15 CEST] <furq> but it just gets stuck downloading the first segment [20:01:48 CEST] <furq> and using the urls directly is just timing out [20:08:07 CEST] <dastan> i try to talk with developpers if someone know something about but it was like to talk with fucking god [20:08:24 CEST] <dastan> i will open a ticket on track this night [20:11:10 CEST] <JEEB> the DASH reader maintainer is not on IRC generally [20:11:16 CEST] <JEEB> and most people don't want to touch the XML [20:11:30 CEST] <JEEB> I think the dash person might notice on trac, yes [20:12:07 CEST] <dastan> thanks jeeb [20:12:47 CEST] <JEEB> also make sure the DASH manifest doesn't have DRM [20:13:03 CEST] <dastan> i readed a lot about dash and this is a change that youtube made yesterday, youtube was transmitting live channels in HLS, and yesterday chenge everything to dash [20:13:08 CEST] <JEEB> see if the DASH manifest contains the word "protection" [20:13:49 CEST] <dastan> i knew about dash yesterday, i really dont know how to access to the mpd manifest [20:14:11 CEST] <JEEB> it should be a HTTP URL? the mpd manifest is just plain text XML [20:14:25 CEST] <JEEB> I don't see a problem in accessing it if youtube-dl can extract it for you [20:14:26 CEST] <JEEB> :P [20:14:59 CEST] <JEEB> you can use curl or whatever to access the URL as well if you really cannot think of any other way of opening it [20:16:38 CEST] <JEEB> heck the url could be opened in a browser :P [20:16:50 CEST] <JEEB> it will probably attempt to download the mpd [21:41:18 CEST] <dastan> already made that [21:41:29 CEST] <dastan> and i dont find the mpd link [21:42:01 CEST] <JEEB> I thought you were getting the link from youtube-dl and giving that to ffmpeg.c? [21:43:14 CEST] <dastan> i send put the command youtube-dl -f 136 -g youtube-link (thats only to get the video link) [21:43:29 CEST] <dastan> and the link i get dont finish in .mpd [21:43:42 CEST] <dastan> it is something strange [21:44:47 CEST] <dastan> http://vpaste.net/IoEXY [21:45:08 CEST] <dastan> this is the outside of the command i told you [21:46:03 CEST] <durandal_1707> perhaps you need to change user-agent? [21:46:41 CEST] <JEEB> dastan: the extension doesn't matter. if it's not a proper MPEG-DASH manifest that's XML then an MPEG-DASH manifest reader will not work [21:47:39 CEST] <dastan> user agent? [21:47:43 CEST] <JEEB> dastan: curling that URL gives you binary data [21:47:48 CEST] <JEEB> that's not an XML manifest [21:47:51 CEST] <dastan> sory but i am not understanding [21:48:10 CEST] <JEEB> < Content-Type: video/mp4 [21:48:16 CEST] <JEEB> so that is a segment or segments [21:48:20 CEST] <JEEB> not a manifest [21:48:21 CEST] <dastan> jeeb: thats what i think, i am not getting the manifest [21:48:34 CEST] <JEEB> then why would you be opening a bug against FFmpeg? [21:48:38 CEST] <JEEB> if you can't even figure out the URL [21:48:48 CEST] <JEEB> go ask youtube-dl people :P [21:48:58 CEST] <JEEB> of course it's possible that there is no proper XML DASH manifest [21:49:06 CEST] <JEEB> most places do MPEG-DASH with their own custom system [21:49:07 CEST] <dastan> i already made, i ask them today morning [21:49:16 CEST] <dastan> and noone answer me [21:49:28 CEST] <JEEB> that is life [21:49:35 CEST] <dastan> so i come to ffmpeg if someone knows how to extract the mpd manifest [21:49:45 CEST] <JEEB> nope [21:50:02 CEST] <JEEB> if there even is one [21:50:14 CEST] <dastan> i think is not a ffmpeg problem, because when i put this link in ffmpeg it gets one samll video of the repo, but not everyone [21:51:20 CEST] <dastan> i used ffmpeg for youtube, because i am adapting ffmpeg to the necesities of my project [21:52:59 CEST] <dastan> i am only asking, is not a requirement [21:53:53 CEST] <dastan> is a requirement for my project, if i cant process videos from youtube i will not possible to make an important part of my project [21:55:08 CEST] <dastan> but is not your fault or a problem of ffmpeg, i am making more likely a proposal, if ffmpeg can process youtube dash can be something great [22:02:23 CEST] <durandal_1707> dastan: you need to know what user-agent means in terms of curl [22:12:30 CEST] <Thomas_J> I am getting a segmentation fault error from my audio channel input. The errors are to cryptic to me to understand. https://pastebin.com/D3qJMpyh [22:14:02 CEST] <JEEB> you'd have to build your own FFmpeg and disable stripping [22:14:08 CEST] <JEEB> --disable-stripping in configure [22:14:18 CEST] <JEEB> that disables removal of debug information from the binaries [22:14:30 CEST] <JEEB> so you can then utilize gdb to run the command and look at where it crashes [22:14:40 CEST] <JEEB> have a gdb tutorial: http://www.unknownroad.com/rtfm/gdbtut/ [22:15:17 CEST] <kurosu> also, the input seems to be video-only, which is a strange condition to crash the audio part [22:16:10 CEST] <JEEB> it doesn't log the second input at that point [22:16:35 CEST] <kurosu> oh right, didn't see the -i hw:CARD=1,0 afterwards [22:19:41 CEST] <Thomas_J> Oh gaads. That's whaat I have been trying to avoid. I fixed the problem that the alsa-lib by adding a soft link to the file system pointing to it. [22:20:50 CEST] <Thomas_J> I am afraid to recompile because I don't know what version of the source is safe for the rtmps fix. [22:22:22 CEST] <Thomas_J> I git cloned the current source from ffmpeg but I am afraid that it may throw me back into no rtmps connectivity. [22:23:22 CEST] <JEEB> you will have rtmps as long as you install gnutls development package [22:23:32 CEST] <JEEB> and you can check during the *configure* phase [22:23:43 CEST] <JEEB> ./configure --enable-gnutls I think :P [22:24:00 CEST] <JEEB> > --enable-gnutls enable gnutls, needed for https support [22:24:03 CEST] <JEEB> yup [22:24:12 CEST] <JEEB> (the configure script has a --help option to list things) [22:26:58 CEST] <Thomas_J> Okay, It shouldn't really be a problem since I clone each version in it's own directory and test it from there. [22:27:52 CEST] <Thomas_J> I ahve a whole bunch of cleanup th do once I get one working. [22:28:38 CEST] <furq> Thomas_J: run gdb anyway and see if you get anything useful [22:31:11 CEST] <JEEB> Thomas_J: you can utilize a single clone and multiple build directories. as long as you haven't run configure in the source root :) [22:31:31 CEST] <JEEB> like in my case I've got plenty of xxx_build directories next to or within the FFmpeg source directory, and I just call the configure script from there :) [22:32:43 CEST] <Thomas_J> Thanks for that. I waas just about to run ./configure. I'll copy the directory before running it. [22:33:02 CEST] <JEEB> nah, just make a directory and call the script *from* it [22:33:18 CEST] <furq> mkdir foo_build; cd foo_build; ../configure [22:33:18 CEST] <JEEB> like, if you make a directory next to the configure script, it's "../configure" instead of ./configure [22:33:49 CEST] <Thomas_J> Right now I'm reading the gdb configuration but don't see anything there that sticks out. [22:34:09 CEST] <JEEB> for gdb you should just read the tutorial I pointed out some time ago :) [22:34:19 CEST] <furq> pretty much just `gdb --args ffmpeg ...` `run` then wait for it to segfault and `bt` [22:34:28 CEST] <JEEB> yes [22:34:30 CEST] <JEEB> that's the gist of it [22:34:38 CEST] <Thomas_J> Yup! got it. [22:35:17 CEST] <Thomas_J> configure runs from it's own directory and builds where you are at? [22:35:27 CEST] <furq> it runs in the working directory [22:35:44 CEST] <furq> also if you don't actually write much C then that is pretty much 100% of what you need to know about gdb [22:35:52 CEST] <furq> that's basically all i remember how to do with it [22:35:59 CEST] <JEEB> well, "bt full" is sometimes useful :) [22:36:04 CEST] <furq> true [22:36:09 CEST] <another> ffmpeg can do out-of-source builds? [22:36:16 CEST] <JEEB> yes [22:36:25 CEST] <JEEB> as long as you haven't already once configured it in-source [22:36:26 CEST] <Thomas_J> I haven't written C since the late 80s. [22:36:39 CEST] <JEEB> I think if it finds some things it generates it will bark at you [22:38:32 CEST] <Thomas_J> In the 70s, I programed in Basic and dropped into machine code when I need to soeed things up. [22:39:01 CEST] <Thomas_J> Processors were simple back then. [22:39:45 CEST] <JEEB> Thomas_J: and now you have multimedia stacks that make you think that you might want whatever the designers were smoking [22:39:50 CEST] <JEEB> like, MMTP over TLV [22:40:11 CEST] <Thomas_J> I gave that up too. [22:40:28 CEST] <JEEB> TLV is not even multimedia, it's a way of transferring IP over <something> [22:40:43 CEST] <JEEB> and then that contains multicast streams usually [22:40:57 CEST] <JEEB> which then contain MMTP which is mp4-based funky stuff [22:41:53 CEST] <Thomas_J> I am not even considering that all this that I am learning will stick with me. I think Senility is slowly sinking in. [22:43:16 CEST] <ossifrage> Any ideas how to get rtsp-like latency with web based protocols? Is there an even remotely standard way of doing video over WebRTC [22:44:05 CEST] <Thomas_J> Oh ya, my IP cameras respond to that to identify themselves. [22:44:07 CEST] <JEEB> ossifrage: all the players seem to be custom solutions at least, while I see at least one media server that at least a couple of people seem to have used [22:44:29 CEST] <JEEB> https://github.com/aiortc/aiortc [22:44:36 CEST] <JEEB> supposedly usable for the media serving part? [22:47:55 CEST] <ossifrage> mp4 really sucks for live streaming which really [22:48:11 CEST] <nine_milli> blb_ [22:49:44 CEST] <ossifrage> I'm using live555 for rtsp which was really low pain, but isn't really suitable for my end goal [22:50:45 CEST] <ossifrage> I bodged a hls/dash test which worked better then I expected but the latency sucked and things that help the latency really hurt the compression efficiency [22:52:23 CEST] <ossifrage> I get around 300-400ms end-to-end latency with 'mpv --profile=low-latency' with rtsp [22:53:35 CEST] <JEEB> well, HLS/DASH really aren't for low latency. people start doing hacks to make it appear as if the latency is lower, while in the end you have to go for proper streaming connections to get lowest latency [22:54:42 CEST] <Thomas_J> Once again, what 2 enables do I need for this build? gnu something and stripper sonething? [22:55:17 CEST] <JEEB> --help parameter and grep -E "(stripping|gnutls)" [22:55:18 CEST] <JEEB> :) [22:55:28 CEST] <Thomas_J> Thanks. [22:57:07 CEST] <ossifrage> I think my primary goal is good compression efficiency, so I'm not willing to sacrifice compression for latency. [22:57:43 CEST] <JEEB> you don't really have to, since "how long does it take 'til first decoded image" != "latency" [22:57:45 CEST] <ossifrage> And I'm not so concerned about startup delay, waiting till the start of the next GOP is fine [22:58:56 CEST] <ossifrage> The fmp4 stuff I've played with outputs 1 gop at a time. the rtp stuff is frame at a time [22:59:40 CEST] <JEEB> there's nowadays an option in movenc that fragments on each video sample (I think) [23:00:48 CEST] <JEEB> > frag_every_frame [23:00:51 CEST] <JEEB> in movflags [23:01:30 CEST] <Thomas_J> --disable-stripping? I'm missing a couple of header files. [23:02:02 CEST] <ossifrage> JEEB yeah I was playing around with that frag_every_frame+delay_moov+skip_trailer [23:02:29 CEST] <JEEB> Thomas_J: that option doesn't require anything, so it's something else if it's complaining about something. and as I noted for --enable-gnutls you need the debian gnutls development package [23:02:58 CEST] <ossifrage> the ffmpeg muxer was just writing a gop to /tmp and the webserver was effectively doing tail -f on the file in /tmp [23:03:36 CEST] <JEEB> ossifrage: if it was full GOPs then something wasn't working as expected I think :D [23:03:44 CEST] <JEEB> since the idea of it was to push each frame as its own fragment [23:03:56 CEST] <JEEB> Thomas_J: apparently the debian package is something like libgnutls28-dev [23:05:01 CEST] <ossifrage> JEEB, I was getting 1 frame in 1 frame out of the muxer (I was just writing them to the same file as a placeholder for doing something less stupid) [23:08:44 CEST] <ossifrage> I liked the idea of DASH/HLS mostly because I have enough spare cycles to encode several different versions of the camera data. [23:10:54 CEST] <ossifrage> The camera needs to be able to do live streaming, streaming of recent history (say 30s in the past), local archival streaming and then selective external archival [23:32:44 CEST] <Thomas_J> I'm missing 2 files, frei0r.h dlfcn.h. I ran into this a while back but forgot what I did to fix this. [23:33:12 CEST] <JEEB> Thomas_J: do you really need freior etc? [23:33:17 CEST] <JEEB> or are you just copypasting options from somewhere? [23:34:30 CEST] <furq> dlfcn.h is in libc6-dev on debian [23:34:32 CEST] <Thomas_J> I think I just removed it's enable in the config instructions last time, I think. [23:34:37 CEST] <furq> although if you don't have that then you probably can't build anything at all [23:35:20 CEST] <Thomas_J> I removed --enable-frei0r [23:35:27 CEST] <furq> that works too [23:37:51 CEST] <Thomas_J> ERROR: gnutls not found using pkg-config [23:38:19 CEST] <JEEB> did you install gnutls development package? [23:40:28 CEST] <Thomas_J> Yes. It looks like I'm going to have to make another directory forward link. [23:41:16 CEST] <Thomas_J> It works with the prebuilt bin. [23:41:20 CEST] <kepstin> uhh... [23:42:11 CEST] <JEEB> Thomas_J: no, it should work with the gnutls -dev package :P [23:42:17 CEST] <JEEB> already packaged in raspbian [23:42:19 CEST] <kepstin> you shouldn't have to make any manual links for anything... when you install the dev package, it installs a pkg-config file that ffmpeg's configure script will find, and it'll use that to set the dirs correctly [23:43:37 CEST] <kepstin> is the problem that you're missing pkg-config, maybe? [23:44:03 CEST] <JEEB> that could be quite likely :) [23:45:16 CEST] <Thomas_J> Very well could be. the error in the build log is cannot find in the pkg-config search path. [23:46:05 CEST] <kepstin> hmm, that means that it ran pkg-config but couldn't find the gnutls pc file [23:46:19 CEST] <JEEB> Thomas_J: ffbuild/config.log [23:46:25 CEST] <JEEB> that gives the exact error at the end of it [23:47:30 CEST] <Thomas_J> I found it in /var/lib/dpkg/info/ [23:47:58 CEST] <kepstin> please don't break your system more by messing inside dpkg internals [23:49:40 CEST] <kepstin> if running `pkg-config --path gnutls` either gives an error or blank output, then either you never actually installed the gnutls dev package, or your system is otherwise busted in a way out of scope of ffmpeg. [23:49:50 CEST] <Thomas_J> https://pastebin.com/J9WwiLxj [23:50:45 CEST] <JEEB> and you have the pkg-config binary installed? [23:51:04 CEST] <kepstin> yes, that "was not found in the pkg-config search path" is pkg-config output [23:51:10 CEST] <JEEB> ok [23:51:27 CEST] <JEEB> Thomas_J: is libgnutls28-dev installed? [23:52:09 CEST] <Thomas_J> ln -s doesn't break anything. It just ads a link to where the package is trying to look for something. I had to do that for libasound2. [23:52:12 CEST] <kepstin> it might be a different version depending on the exact debian release? I think you can do "apt-get install gnutls-dev" (that's a virtual package name) and it should pull in the right one [23:52:37 CEST] <Thomas_J> Let me check [23:53:17 CEST] <JEEB> `apt list --installable |grep -E "gnutls.*-dev"` might bring it up as well [23:53:41 CEST] <Thomas_J> Nope it wasn't. [23:53:44 CEST] <JEEB> argh, no that was not the proper option [23:54:05 CEST] <JEEB> ok, just `apt list` [23:54:13 CEST] <Thomas_J> Installed now [23:54:44 CEST] <kepstin> wow, an hour of troubleshooting to go from "you need to install the gnutls dev package" to "oh, i didn't install the gnutls dev package" :/ [23:55:26 CEST] <Thomas_J> Still not finding gnutls. [23:56:48 CEST] <JEEB> Thomas_J: find / -iname '*gnutls*.pc' ? [23:56:50 CEST] <Thomas_J> OOPS! I thaught it was finished installing. It's apt is still installing it. [23:56:54 CEST] <JEEB> heh [23:57:01 CEST] <JEEB> ok, just wait until it's installed :P [23:57:02 CEST] <Thomas_J> :( [23:57:23 CEST] <JEEB> kepstin: yes, I have wasted quite a few hours thinking this person was on master as I specifically noted "git master" to be utilized :P [23:57:32 CEST] <JEEB> just to find him on 4.1.x [23:59:17 CEST] <Thomas_J> got another one. ERROR: aom >= 1.0.0 not found using pkg-config [23:59:26 CEST] <JEEB> why did you install something you will not be using? [23:59:32 CEST] <JEEB> or well, attempt to enable [23:59:47 CEST] <JEEB> literally start with --enable-gnutls only as an option [00:00:00 CEST] --- Fri Jul 12 2019

1 0

ffmpeg-devel.log.20190710
by burek 11 Jul '19

11 Jul '19

[11:27:33 CEST] <cone-761> ffmpeg 03Steven Liu 07master:24f7a8a1688f: avformat/dashdec: fix code style and remove some empty line [12:59:09 CEST] <cone-761> ffmpeg 03Shiyou Yin 07master:a45e8ade2d2d: avutil/mips: optimize UNPCK&SAD macros with MSA2.0 instruction. [12:59:10 CEST] <cone-761> ffmpeg 03YunQiang Su 07master:925e33b253c8: avcodec/mips/cabac: replace addi with addiu [12:59:11 CEST] <cone-761> ffmpeg 03Cameron Cawley 07master:94d45a13c7e8: avformat/rpl: Replace strcpy with av_strlcpy [12:59:12 CEST] <cone-761> ffmpeg 03James Zern 07master:b1febda06195: avcodec/utils, avcodec_open2: close codec on failure [13:24:51 CEST] <JEEB> michaelni: /2 [13:25:12 CEST] <JEEB> uhh, what I meant is - what branches should a fix go into? [13:25:42 CEST] <JEEB> mostly the gnutls fix that i merged some time ago [13:26:35 CEST] <BtbN> I usually just backport fixes to all branches where it applies cleanly or with minimal fuzz [16:00:52 CEST] <BBB> uh oh [16:01:19 CEST] <durandal_1707> ? [16:02:11 CEST] <BBB> Your message wasn't delivered to cenx.yan(a)intel.com because the address couldn't be found, or is unable to receive mail. [16:05:25 CEST] <jamrial> that was the cc. i assume he'll still get it on his gmail account [16:08:22 CEST] <cone-879> ffmpeg 03Paul B Mahol 07master:57a2688fe388: avfilter/af_afftfilt: make selecting window size simpler [16:08:22 CEST] <cone-879> ffmpeg 03Paul B Mahol 07master:74d4fd0822c3: avfilter/avf_showfreqs: make selecting window size simpler [16:29:50 CEST] <dastan> hello people [16:30:09 CEST] <dastan> someone know how to convert from 30 to 60 without getting dup frames? [16:31:00 CEST] Last message repeated 1 time(s). [16:32:16 CEST] <gnafu> dastan: Do you mean you want to effectively speed up the video by double, or something else? Anyway, I think this question is better suited for #ffmpeg, as this channel is for ffmpeg development and not use. [16:36:32 CEST] <dastan> gna [16:36:35 CEST] <dastan> gnafu [16:36:45 CEST] <michaelni> JEEB, depends, but important fixes should ideally go to all releases which are still used by some projects (https://trac.ffmpeg.org/wiki/Downstreams) [16:39:46 CEST] <dastan> ffmpeg decklink module only support 50 or 60 fps in 720, do you know if there is a way to make it capable to support 25 and 30 fps? [16:40:44 CEST] <durandal_1707> dastan: try to contact decklink module code maintainer in ffmpeg [16:41:01 CEST] <dastan> what are the most compatible SDI cards for FFmpeg? i saw there are some other brands like matrox [16:41:29 CEST] <dastan> durandal, who is he [16:41:32 CEST] <dastan> ? [16:41:40 CEST] <dastan> michaelni? [16:41:47 CEST] <durandal_1707> nope [16:42:40 CEST] <durandal_1707> marton ballint [16:42:58 CEST] <durandal_1707> single l [16:43:12 CEST] <dastan> but the decklink problem is that the cards dont support 25 or 30 fps in 720, but there is a limitation of the module, because the cards support those types of video [16:44:10 CEST] <dastan> ok, and do you know which cards are more compatible with ffmpeg? [16:49:08 CEST] <durandal_1707> me? nope, i know very little about it [16:50:04 CEST] <dastan> ok [16:50:51 CEST] <dastan> if someone else know about SDI OUT/IN in FFmpeg and which cards are the best option feel free to share the knowledge .... :) [17:48:31 CEST] <dastan> i have a video that is 48 mins [17:48:54 CEST] <dastan> when i put the video to sart from the minute 47 it says too many packets buffered [17:48:58 CEST] <dastan> my command is [17:49:04 CEST] <dastan> ffmpeg -ss 00:47:00 -f mpegts -i /home/build/MSS-ONE/temp/decklink.ts [17:49:11 CEST] <dastan> someone know what is the problem? [18:40:24 CEST] <durandal_1707> i will write cineform encoder for coins [00:00:00 CEST] --- Thu Jul 11 2019

1 0

ffmpeg.log.20190710
by burek 11 Jul '19

11 Jul '19

[00:12:24 CEST] <switchnode> the output of `ffmpeg` is colored in the terminal, uncolored if passed to a pipe. is there a way to disable this behavior (as in e.g. ls's --color=always)? [00:13:15 CEST] <furq> AV_LOG_FORCE_COLOR=1 [00:13:41 CEST] <furq> https://www.ffmpeg.org/ffmpeg.html#Generic-options [00:13:43 CEST] <furq> under -loglevel [00:15:15 CEST] <switchnode> ah, perfect. thanks. [00:38:00 CEST] <pzy> I have a stupid MP4 that contains mostly 720p60 video, but some 1080p30 parts because streaming is stupid [00:38:19 CEST] <pzy> can ffmpeg delete or extract frames from a video based on frame resolution? [00:39:32 CEST] <BtbN> Does mp4 even support that, given that the extradata with that kind of stuff is not stored inline with the video? [00:39:48 CEST] <pzy> it "supports" it but wow do players hate it [00:39:57 CEST] <pzy> "This works because the stream consists of special NAL units which indicate the frame size for the following sequence. When you wrap it in a container, these NAL units are removed and the information about when the frame size changes is put in the container's global header." [00:41:24 CEST] <BtbN> Yeah, and mp4 only has one global header, unless it's fmp4 [00:42:22 CEST] <pzy> I guess the container doesn't matter, since it's just dumping the HLS into whatever [00:42:31 CEST] <pzy> I just need to get rid of those pesky 1080p segments [01:34:26 CEST] <sine0> I have a video and I want to slow it down a bit. its 25 fps, I want it still to be 25fps but slow. I guess my options is to interpolate, right ? also is this what the popular twixtor does ? [02:36:12 CEST] <relaxed> Thomas_J: I always provide the current release, bugs and all [04:16:04 CEST] <nine_milli_> blb_ [07:15:17 CEST] <MoziM> so is there any ffmpeg based package you all know of that continuously records the desktop but only while there's motion on the screen? [16:23:08 CEST] <dastan> hello people [16:23:40 CEST] <dastan> i am getting an error and i dont know how to solve it [16:23:59 CEST] <durandal_1707> what error? [16:24:32 CEST] <dastan> i am getting some videos from youtube that are in 30 fps and i need to download first and resend the video over a decklinks card [16:26:51 CEST] <dastan> ffmpeg decklink module only support 50 or 60 fps in 720, so i make the configuration from 30 to 60, but when i want to put it in the decklink, it shows me a duplicated frames errors and after ten minutes it stop sending video [16:27:35 CEST] <dastan> someone know how to convert from 30 to 60 without getting dup frames? [16:28:29 CEST] <dastan> and the other question, can someone of the developper tell us why the decklink module dont support 25 and 30 fps over decklink cards? [16:28:53 CEST] <dastan> does someone knows if another cards, like matrox, are more compatible with FFMPEG? [16:33:25 CEST] <durandal_1707> i do not have such card so I couldn't help you [16:36:11 CEST] <dastan> if you send a video that originally was in 30 fps to another location in udp but in 60fps you will see the dup frames [16:36:22 CEST] <dastan> dont need a decklink card? [16:36:53 CEST] <durandal_1707> dastan: do you want to motion-interpolate missing frames ? [16:38:34 CEST] <Mavrik> dastan: what kind of card is that? [16:38:39 CEST] <Mavrik> SDI? HDMI? Composite? [16:41:53 CEST] <dastan> sdi [16:50:12 CEST] <kexec> hello, please how to do in linux bash incrementing output file names (1.mkv, 2.mkv, ...)? [16:51:30 CEST] <dastan> you want to process the same video two tiomes? [16:53:20 CEST] <kexec> dastan: no, i want to convert all videos in a folder (through for) [16:57:36 CEST] <steve___> kexec: cd /path/to/folder; for i in *.mkv; do CMD; done [16:58:49 CEST] <kexec> steve___ yeah i have that but how should i set the output file name in ffmpeg? [17:15:14 CEST] <MoziM> is there a way to remove duplicate frames as ffmpeg is recording instead of doing it at the end? [17:21:39 CEST] <steve___> kexec: in bash you can do "${i/.mkv/-new.mkv"} [17:21:49 CEST] <steve___> kexec: in bash you can do "${i/.mkv/-new.mkv}" [17:27:31 CEST] <N4ppeL> Hi all. So I managed to encode a video made from grayscale images with format=gray using libx264, the funny part is: its bigger than with yuv420p. Is this a problem in ffmpeg or rather libx264 and should I even file it as an issue? [17:28:03 CEST] <ChocolateArmpits> N4ppeL, What other settings did you use? [17:28:58 CEST] <N4ppeL> high profile (but it sometimes gets ignored by preset ultrafast) [17:29:39 CEST] <N4ppeL> heres the full command [17:29:39 CEST] <N4ppeL> https://pastebin.com/CniBt1zz [17:30:37 CEST] <N4ppeL> output below the command is however outdated (i upgraded to 4.1.3 which ran the command successfully) [17:31:36 CEST] <furq> i suspect that bit contains the useful information [17:31:40 CEST] <furq> x264 [error]: high profile doesn't support 4:4:4 [17:31:43 CEST] <furq> this looks like a clue though [17:32:26 CEST] <N4ppeL> I can run it again and post the full output [17:32:27 CEST] <N4ppeL> but [17:32:45 CEST] <N4ppeL> its not crucial for me. I was just wondering why the final size is bigger [17:32:54 CEST] <N4ppeL> and whether its a bug that should be filed [17:54:10 CEST] <dastan> i have a video that is 48 mins [17:54:20 CEST] <dastan> when i put the video to sart from the minute 47 it says too many packets buffered [17:54:27 CEST] <dastan> my command is [17:54:36 CEST] <dastan> ffmpeg -ss 00:47:00 -f mpegts -i /home/build/MSS-ONE/temp/decklink.ts [17:55:02 CEST] <dastan> someone know what is the problem? [17:55:12 CEST] <JEEB> provide a full command line and terminal output with at least -v verbose in a pastebin and link it here [17:56:33 CEST] <dastan> [graph_1_in_0_1 @ 0x55bfad5d9f00] tb:1/48000 samplefmt:s16p samplerate:48000 chlayout:0x3 [17:56:33 CEST] <dastan> x55bfad43bfc0] Reinit context to 1280x720, pix_fmt: yuv420p [17:56:52 CEST] <dastan> ffmpeg -v verbose -ss 00:46:00 -f mpegts -i /home/build/MSS-ONE/temp/decklink.ts -vcodec v210 -r 60 -s 1280x720 -acodec pcm_s16le -ac 2 -ar 48000 -f decklink 'DeckLink SDI (1)' [17:57:51 CEST] <ZeroWalker> wasn't there two ways to cut losslesly with ffmpeg, one that cuts at keyframe, other that cut anywhere and aligns with the audio [17:59:41 CEST] <JEEB> dastan: don't cut things, just provide a text file on a web server or pastebin or whatever [17:59:46 CEST] <JEEB> and link here [17:59:56 CEST] <JEEB> with the full command line and terminal output [18:01:00 CEST] <ChocolateArmpits> N4ppeL, well you're not really specifying any bitrate related settings in any of your outputs [18:01:30 CEST] <N4ppeL> yes, but that shouldnt matter should it? [18:01:40 CEST] <ChocolateArmpits> I don't know if it's fair to expect the default properties to somehow remain true in both cases [18:01:52 CEST] <N4ppeL> I mean... gray should basically be YUV420 but ...well, just the Y channel [18:01:57 CEST] <N4ppeL> how can it be bigger? [18:02:01 CEST] <ChocolateArmpits> I would probably try crf and then compare how the two format fare [18:02:09 CEST] <ChocolateArmpits> formats* [18:03:58 CEST] <ChocolateArmpits> N4ppeL, it also writes "yuvj444p for H.264 encoding chosen", doesn't look like gray to me [18:04:28 CEST] <N4ppeL> well, yes, its the old output of ffmpeg 3.2 that didnt even run the command through. On 4.1.3 it did [18:04:38 CEST] <N4ppeL> as stated i can re-run and paste [18:04:47 CEST] <ChocolateArmpits> would be good so we stay on the same page [18:05:16 CEST] <N4ppeL> sure. [18:06:37 CEST] <N4ppeL> ah well. I do not state any bitrate, true, but i do give a quality [18:09:11 CEST] <N4ppeL> no i dont. Sorry. [18:11:35 CEST] <N4ppeL> ffmpeg states a default crf of 23 though. But I will still try to set it explicitly. Is there a fine tool to compare the quality differences of the output? [18:13:21 CEST] <ChocolateArmpits> N4ppeL, ffmpeg has ssim and psnr filters for that [18:13:44 CEST] <N4ppeL> of course it does :) [18:14:42 CEST] <JEEB> N4ppeL: the CRF default depends 100% on the encoder [18:14:47 CEST] <JEEB> 23 is the default of the libx264 encoder [18:14:56 CEST] <JEEB> (which is actually not the FFmpeg default but the library default) [18:15:10 CEST] <JEEB> so if x264 was to switch the default somewhere else it'd become that :P [18:15:22 CEST] <dastan> i am not understanding [18:15:25 CEST] <JEEB> N4ppeL: also I recommend just encoding like 2500 frames or so with -ss and -t [18:15:29 CEST] <dastan> is only the time start [18:15:46 CEST] <JEEB> with different CRF values [18:15:58 CEST] <JEEB> then you will probably figure out the highest CRF value that still looks good enough for you [18:16:00 CEST] <dastan> i only want to thart from the point x that is minute 47 [18:16:06 CEST] <N4ppeL> hm well technically ffmpeg could specify its own default and explicitly pass it to libx264, but if you say that is not what is happening i believe it [18:16:20 CEST] <JEEB> yes, technically the libx264 wrapper could do that [18:16:53 CEST] <JEEB> the crf option is specific to the module (libx264 wrapper) [18:17:05 CEST] <JEEB> and the default I think is zero [18:17:21 CEST] <JEEB> ah no [18:17:22 CEST] <JEEB> { "crf", "Select the quality for constant quality mode", OFFSET(crf), AV_OPT_TYPE_FLOAT, {.dbl = -1 }, -1, FLT_MAX, VE }, [18:17:26 CEST] <JEEB> so the default is -1 :) [18:17:46 CEST] <JEEB> also it's not really "constant quality", and I've been reprimanded about that by one of the x264 authors in my younger days :P [18:17:57 CEST] <N4ppeL> heres my source for comparison... https://trac.ffmpeg.org/wiki/Encode/H.264 [18:18:17 CEST] <furq> N4ppeL: could you maybe reproduce this with a smaller command line [18:18:39 CEST] <JEEB> N4ppeL: basically probably user provided text and for them it's the same if it's FFmpeg's default or libx264's ;) [18:18:46 CEST] <furq> i just tried replicating it here and i get a smaller result for 4:0:0 [18:18:57 CEST] <N4ppeL> @furq hell yes i am on it [18:19:17 CEST] <uartie> It was suggested on ML (RE: add rawdump filter) that the "split" filter could be used. But the whole point of "rawdump" is so we can dump all frames unscaled. I don't see how "split" can avoid the auto-inserted scaler. Is that possible? [18:19:22 CEST] <JEEB> since the end result with the libx264 wrapper is that CRF 23 is what you end up with by default [18:19:30 CEST] <N4ppeL> what's -ss -t btw? [18:19:36 CEST] <JEEB> -ss seeks to X seconds [18:19:41 CEST] <JEEB> -t encodes X seconds [18:19:50 CEST] <JEEB> so if you know a good point in your longer clip that you want to iterate over [18:20:06 CEST] <JEEB> then you use those options to not encode the whole clip [18:20:07 CEST] <furq> [libx264 @ 0000017fc5808b80] profile Constrained High, level 1.3, 4:0:0, 8-bit [18:20:08 CEST] <JEEB> for testing purposes [18:20:12 CEST] <furq> i had no idea this was a thing [18:31:43 CEST] <N4ppeL> ok so: https://pastebin.com/QXnAcQZF [18:32:20 CEST] <N4ppeL> there are 4 commands: 1. yuv420p, 2. yuv420p and -crf 23 3. gray and -crf 23 4. gray [18:32:48 CEST] <JEEB> btw if you have filter chains etc I recommend -v verbose [18:32:58 CEST] <JEEB> it doesn't spam, but it gives you some extra logging [18:33:00 CEST] <N4ppeL> file sizes is both times 296 KB for yuv and 352 for gray [18:33:43 CEST] <JEEB> also CRF between completely different things isn't really comparable, sorry. [18:34:07 CEST] <JEEB> I think if you want a simple check then probably using lossless for both is better [18:34:34 CEST] <JEEB> that or you have to start graphing some metrics or whatever :/ [18:34:34 CEST] <N4ppeL> it should not be that much different [18:34:39 CEST] <N4ppeL> output is a grayscale video [18:34:49 CEST] <N4ppeL> in both cases [18:34:58 CEST] <N4ppeL> since the input images are only grayscale.. [18:35:37 CEST] <JEEB> I'm just noting that unfortunately "I just used the same CRF value" is not the same quality if you have changed parameters [18:35:59 CEST] <JEEB> if you want an easy to do comparison, utilize -q:v 0 [18:36:01 CEST] <JEEB> which is lossless [18:36:16 CEST] <JEEB> because your preset would end up being the same by default (preset medium9 [18:37:49 CEST] <JEEB> and I do recommend -v verbose since it f.ex. logs the full creation of the filter chain [18:38:06 CEST] <JEEB> in the API there's actually an option to disable auto-inserted format conversions [18:38:13 CEST] <JEEB> unfortunately the command line app doesn't have an option for that :) [18:39:43 CEST] <dastan> so there is no option to start playing the video from a x point [18:39:54 CEST] <dastan> only if it is less than 45 minutes [18:40:02 CEST] <JEEB> dastan: have you provided any info requested? [18:40:15 CEST] <dastan> which one? [18:40:26 CEST] <dastan> i already send the log [18:40:29 CEST] <furq> N4ppeL: fwiw there is no reason to use -level 5.1 there [18:40:30 CEST] <JEEB> full command line and terminal output preferably with -v verbose in a pastebin or so [18:40:30 CEST] <dastan> and the command [18:40:39 CEST] <JEEB> dastan: so you linked it at some point? [18:40:41 CEST] <furq> idk if that would throw things off but 512x512 4:0:0 would be like level 2 or something [18:41:04 CEST] <N4ppeL> I was told it gets ignored with preset ultrafast anyway, so, yeah. [18:41:18 CEST] <furq> well it tells x264 to flag the stream as 5.1 [18:41:18 CEST] <dastan> [graph_1_in_0_1 @ 0x55bfad5d9f00] tb:1/48000 samplefmt:s16p samplerate:48000 chlayout:0x3 [18:41:18 CEST] <dastan> x55bfad43bfc0] Reinit context to 1280x720, pix_fmt: yuv420p [18:41:28 CEST] <dastan> ffmpeg -v verbose -ss 00:46:00 -f mpegts -i /home/build/MSS-ONE/temp/decklink.ts -vcodec v210 -r 60 -s 1280x720 -acodec pcm_s16le -ac 2 -ar 48000 -f decklink 'DeckLink SDI (1)' [18:41:48 CEST] <furq> so if nothing else you should probably just let it have the right flag set [18:41:51 CEST] <JEEB> dastan: full log, in a text file or pastebin. not just bits and pieces that have nothing to do with it [18:42:13 CEST] <dastan> i only receive that [18:42:32 CEST] <JEEB> add 2> ffmpeg_sucks.log [18:42:32 CEST] <dastan> ffmpeg dont start when i put more then 45 minutes in the -ss flag [18:42:34 CEST] <JEEB> at the end :P [18:42:51 CEST] <JEEB> then check the file at the end of it [18:44:27 CEST] <dastan> i am creating a video with another ffmpeg process that is 01:45:30 and growing (is created from a youtube live conection) and is muxed in mpegts with h264 codec [18:44:52 CEST] <JEEB> please just provide the log instead of wriggling around. if it has some secret keys or file names you can just change that shit [18:45:02 CEST] <JEEB> if you do not want to provide that, do not expect help in resposne [18:45:36 CEST] <dastan> then i take that video from a point to stream to the decklink, so, if the video i am creating as a cache is is 01:43:50 i want to stream to the sdi from the point 01:43:25 [18:45:53 CEST] <dastan> theres is no s [18:45:58 CEST] <dastan> there is no secret [18:46:32 CEST] <dastan> is that i am dont doing nothing else, i am providing what i have [18:46:50 CEST] <dastan> i can give you a teamviewer acess by private if you want [18:48:35 CEST] <JEEB> no you clearly are not providing what you have [18:48:50 CEST] <JEEB> I even told you how to dump the standard error output into a goddamn file [18:49:06 CEST] <JEEB> yet you still have focused on saying that you have provided everything evne though you clearly have not [18:49:40 CEST] <JEEB> also for the record, with an mp4 file here if I do -ss to 47min+ it works just fine, so whatever the flying dog fungus is happening in your case is specific to some things that are specific to YOUR USE CASE [18:49:51 CEST] <JEEB> so please understand that to help you we need your logs [18:49:52 CEST] <dastan> tell me what to do and i will do [18:50:10 CEST] <JEEB> `<YOUR FFMPEG COMMAND> 2> ffmpeg_sucks.log` [18:50:16 CEST] <JEEB> with the failing command with -v verbose [18:50:24 CEST] <JEEB> then provide me the contents of ffmpeg_sucks.log [18:50:33 CEST] <JEEB> link it on the channel [18:50:38 CEST] <JEEB> either through pastebin or whatever you like [18:51:44 CEST] <JEEB> 2 is "standard error" there, and "2>" is "redirect standard error" and the file name after that is where it gets redirected in the current working directory [18:51:58 CEST] <dastan> i have the log of the command in a file [18:52:07 CEST] <dastan> where i can send it to you [18:52:21 CEST] <dastan> i dont have pastebin access [18:52:23 CEST] <JEEB> whatever means is convenient to you. be it pastebin.com, gist.github.com or whatever [18:52:32 CEST] <JEEB> your web server, even [18:52:45 CEST] <JEEB> I personally do not care how you provide the access as long as it is not insane [18:53:39 CEST] <dastan> i am asking for help so i am the most interested in given you access to the information [18:54:46 CEST] <JEEB> I have given alternatives, and there are plenty of other ones as well [18:55:07 CEST] <JEEB> just by searching for pastebins you can probably find a few in addition to those I mentioned [18:56:14 CEST] <Thomas_J> I needed help co I signed up for pastebin.com and now I'm streaming with ffmpeg. [18:56:27 CEST] <JEEB> you don't evn need to sign up for anything I think? [18:56:40 CEST] <JEEB> also if you don't need a web interface you can even use curl and 0x0.st [18:57:05 CEST] <dastan> i am searching an alternative to pastebin [18:57:09 CEST] <JEEB> curl -F'file=@/path/to/file' https://0x0.st [18:57:15 CEST] <JEEB> if you are on something with curl [18:57:26 CEST] <JEEB> then it gives you back the url to your file [18:57:27 CEST] <JEEB> :P [18:57:48 CEST] <Thomas_J> They do like you to have an account and log in just to keep spammers off. It only takes a minute and all they want it your email and set a password. [18:57:51 CEST] <Hello71> http://google.com/search?q=pastebin+alternative [18:59:24 CEST] <Thomas_J> I'm curious. What problem do you have with pastebin? [18:59:57 CEST] <Thomas_J> I just signed up the other day. Should I be worried? [19:00:13 CEST] <BtbN> It's riddled with ads and trackers [19:00:31 CEST] <dastan> https://docs.google.com/document/d/1RE08fEki3D02CuETMNJddg5UvzoZRzW5ez9Nao6… [19:00:32 CEST] <N4ppeL> hmm JEEB it seems you're right that the gray version is also higher quality [19:00:38 CEST] <dastan> i make it with google docs [19:00:45 CEST] <dastan> this is the log of my commans [19:00:50 CEST] <JEEB> dastan: I wouldn't call it sane but thank you [19:00:59 CEST] <Thomas_J> There isn't a website on this Earth dhat isn't. If you Google, They are the worst. [19:01:00 CEST] Action: JEEB opens a private window and all that jazz [19:01:17 CEST] <dastan> ffmpeg -v verbose -ss 01:43:00 -f mpegts -i /home/build/MSS-ONE/temp/decklink.ts -vcodec v210 -r 60 -s 1280x720 -acodec pcm_s16le -ac 2 -ar 48000 -f decklink 'DeckLink SDI (1)' 2>irc [19:01:30 CEST] <dastan> this is the command [19:01:50 CEST] <N4ppeL> hah, fun, fun ,fun ;) will try to measure PSNR against lossless tomorrow to verify my assumption [19:02:02 CEST] <JEEB> N4ppeL: you could just switch from crf 23 to -q:v 0 [19:02:06 CEST] <JEEB> which should be quantizer zero [19:02:07 CEST] <JEEB> aka lossless [19:02:11 CEST] <JEEB> not exactly the same as lossy coding [19:02:16 CEST] <JEEB> but you should be able to get another data point [19:02:23 CEST] <dastan> jeeb, you are talking to me [19:02:37 CEST] <JEEB> dastan: you do not tell me who I am talking to [19:03:05 CEST] <JEEB> anyways, it sounds like for some reason there are no video frames coming in quickly enough [19:03:06 CEST] <Thomas_J> :P [19:03:09 CEST] <dastan> a sory [19:03:19 CEST] <dastan> sory, didnt read [19:03:20 CEST] <N4ppeL> thanks for all the inputs! have a nice evening (or day, night, whatever time it is in your place) [19:03:26 CEST] <JEEB> > Too many packets buffered for output stream 0:1 [19:03:36 CEST] <dastan> yep, that is my log [19:03:39 CEST] <JEEB> this means that ffmpeg.c tried to wait until video became available [19:03:44 CEST] <JEEB> because 0:1 is audio [19:03:58 CEST] <JEEB> dastan: how often are there keyframes in your input? [19:04:42 CEST] <JEEB> also I would recommend the way of saving the log that I noted with the redirection [19:04:47 CEST] <JEEB> most likely simpler :P [19:04:48 CEST] <dastan> ime=02:05:20.78 bitrate=5588.1kbits/s speed=1.01x [19:04:59 CEST] <JEEB> that contains no info regarding that [19:05:03 CEST] <Hello71> lol [19:05:10 CEST] <dastan> jajajaja [19:05:11 CEST] <JEEB> anyways, so you probably do not know, right? [19:05:16 CEST] <dastan> sory [19:05:45 CEST] <JEEB> in any case, additionally seeking in mpeg-ts is not exact because there is no index in mpeg-ts [19:06:01 CEST] <JEEB> so if you are going to do -ss with mpeg-ts you can have fun results. but I think this has more to do with long GOPs [19:06:32 CEST] <dastan> i dont know why if i am creating a video that is based in a transpor stream and i can use the video from the point 00:45:00 or 00:50:00 but not from 01:30:00 [19:07:09 CEST] <pink_mist> did you try 90:00? [19:07:35 CEST] <dastan> not, let me check [19:07:39 CEST] <dastan> only in minutes [19:07:42 CEST] <JEEB> 1) mpeg-ts seeking is not exact 2) mpeg-ts has timestamp discontinuities every 26.5 (IIRC) hours 3) ffmpeg.c does not find a decode'able video frame [19:08:03 CEST] <JEEB> if you want further info on how many things get passed through, utilize -debug_ts [19:08:07 CEST] <JEEB> and post that log [19:08:31 CEST] <dastan> pink, doesent work [19:08:32 CEST] <JEEB> also one thing worth a try is -ss after -i :P although I'm not sure if ffmpeg.c differentiates these any more :P [19:09:55 CEST] <dastan> https://docs.google.com/document/d/1nEPNVDPl4WlyHRv_3cjnxCa_JE4Xau2SvFSuyEq… [19:10:02 CEST] <dastan> jeeb, checj this link [19:10:20 CEST] <dastan> this is the command that i am using to create the mpegts [19:11:19 CEST] <dastan> what i want to do is to take a command to create a file from a HLS input (live channel) [19:11:46 CEST] <dastan> and then take this video as an input of another ffmpeg process to stream to the decklink [19:12:31 CEST] <dastan> so if it is not possible with mpegts muxer, what is the muxer i can use for doing that? [19:12:42 CEST] <JEEB> I know ffmpeg.c probably isn't perfect for this, but have you thought about just having two outputs in your dumping operation? [19:13:12 CEST] <JEEB> ffmpeg -i INPUT [OPTIONS] blah.ts [ANOTHER SET OF OPTIONS] DECKLINK_OUTPUT [19:13:39 CEST] <JEEB> that will of course die if the decklink device errors out or dies [19:15:06 CEST] <JEEB> alternatively, write your .ts in segments (pretty sure there is a module for that), and feed the correct segments to your other process through stdin or something, instead of trying to seek in it? [19:15:18 CEST] <JEEB> because clearly you're hitting a case of not having keyframes or something [19:15:29 CEST] <JEEB> I did note how you can debug the seeking and buffering part, but you seem to have ignored that [19:15:32 CEST] <dastan> HLS is not friendly with decklink [19:15:51 CEST] <dastan> more if the HLS is a youtube link [19:16:22 CEST] <dastan> i am thinking to create a local HLS in separate folder and tes the decklink with a local HLS link [19:17:08 CEST] <JEEB> godspeed is all I can tell you at this point :P [19:20:54 CEST] <dastan> yep [19:21:05 CEST] <dastan> i am testing with HLS local [19:21:17 CEST] <dastan> right now is working [19:22:22 CEST] <dastan> i want to check when the video be like 50 or 70 minutes and i try to open the video staring in the minute 65 65 [21:04:29 CEST] <amosbird> Hello, is it possible to do multiple thread m3u8 downloading using ffmpeg? [21:19:02 CEST] <DHE> probably not [21:22:37 CEST] <DHE> best you can hope for is HTTP keepalive [21:28:35 CEST] <Thomas_J> I can't find a way to open an audio source input in ffmpeg. the use of plughe: command generates "plughw:CARD=1,DEV=0 (No such file or directory)" [21:29:24 CEST] <Thomas_J> Using USB audio adaptor on a raspbian [21:29:32 CEST] <DHE> ffmpeg -devices # does it list your device or API type? [21:30:56 CEST] <Thomas_J> lsusb and aarecord -l both find my usb audio adaptor. [21:33:00 CEST] <Thomas_J> It lists at card:1 dev:0 [21:33:30 CEST] <kepstin> then that would be `hw:1,0` [21:33:46 CEST] <kepstin> might be that the "plug" plugin isn't available in alsa on that device? [21:34:01 CEST] <Thomas_J> I'll try that again but I have also tried that. [21:35:01 CEST] <Thomas_J> cannot open audio device hw:1,0 (No such file or directory) [21:35:02 CEST] <Thomas_J> hw:1,0: Input/output error [21:35:33 CEST] <kepstin> pastebin the complete output please, just in case there's something you're missing :/ [21:35:38 CEST] <another> https://trac.ffmpeg.org/wiki/Capture/ALSA [21:36:19 CEST] <another> my best guess: you're not specifying the format [21:36:31 CEST] <kepstin> or wrong sample rate or something like that [21:37:33 CEST] <another> anyway, unless there's command+log i won't try to debug this [21:37:52 CEST] <kepstin> check your device capabilities with cat /proc/asound/card1/stream0 [21:38:42 CEST] <Thomas_J> https://pastebin.com/0RrfmRqT [21:40:39 CEST] <another> missing - before c:a aac [21:41:08 CEST] <DHE> also wrote it as "acc" [21:41:46 CEST] <another> right [21:42:04 CEST] <Thomas_J> https://pastebin.com/V4ieX1DK [21:42:22 CEST] <Thomas_J> Ouch! [21:43:08 CEST] <kepstin> you might need to use "-channels 1" (default is 2) [21:43:50 CEST] <kepstin> and note that you can just copy/paste one of the device names from "arecord -L" and use that in ffmpeg if you're not sure. [21:44:29 CEST] <Thomas_J> Good to know. [21:47:15 CEST] <Thomas_J> tried -channels 1 before and after the -i hw:1,0 declaration. [21:49:22 CEST] <Thomas_J> arecord -l result: card 1: Device [USB Audio Device], device 0: USB Audio [USB Audio] [21:49:27 CEST] <Thomas_J> Subdevices: 1/1 [21:49:27 CEST] <kepstin> options for a specific input go before the input (-i) option) [21:49:27 CEST] <Thomas_J> Subdevice #0: subdevice #0 [21:49:45 CEST] <kepstin> try using one of the device names from `arecord -L` [21:50:04 CEST] <Thomas_J> Yup but just in case I tried it after also. [21:51:23 CEST] <Thomas_J> remove the parts in perens? [21:51:30 CEST] <kepstin> some ffmpeg options will do *entirely different things* when moved to a different place, some will just give errors, some will be ignored. [21:52:37 CEST] <kepstin> Thomas_J: uhh, there's nothingin in parens in the device names in that output [21:52:43 CEST] <kepstin> or shouldn't be at least [21:52:53 CEST] <another> Thomas_J: arecord -L with a capital L [21:54:24 CEST] <Thomas_J> This is the first line of arecord -l output: [21:54:25 CEST] <Thomas_J> card 1: Device [USB Audio Device], device 0: USB Audio [USB Audio] [21:54:54 CEST] <Thomas_J> OHHH okay with -L [21:55:49 CEST] <another> altough your output suggests that you're missing some libs [22:05:19 CEST] <Thomas_J> Okay. I tried every line in the arecord -L output except the surround sound and no success. [22:05:54 CEST] <Thomas_J> Let me look at the libs. [22:07:03 CEST] <Thomas_J> OOHHHH1 it's looking for pulseaudio instead of alsa. [22:08:45 CEST] <Thomas_J> Well, I have pulseaudio installed. Need to figure out why it can't find it. [22:11:03 CEST] <Thomas_J> Dang! This ffmpeg build doesn't have either pulse or alsa enabled. [22:16:32 CEST] <Thomas_J> I really don't want to go back to compiling ffmpeg all over again but it looks like this bin doesn't hae any audio dupport. [22:26:37 CEST] <another> pretty sure there is alsa support built in https://johnvansickle.com/ffmpeg/git-readme.txt [22:27:15 CEST] <another> ffmpeg -devices [22:27:30 CEST] <another> shows alsa support on my pi [22:27:59 CEST] <Thomas_J> It doesn't show libalsa enabled when it reports it's resources. [22:29:00 CEST] <another> you mean right at the top after "configuration:" ? [22:29:00 CEST] <Thomas_J> I have both alsa and pulseaudio installed. but not enabled in my ffmpeg binary. [22:30:10 CEST] <Thomas_J> Each time ffmpeg is run, it reports all enabled processes that it was compiled with. That's what I am reffering to. [22:30:36 CEST] <another> no [22:30:48 CEST] <another> it reports all config options [22:30:56 CEST] <another> not including defaults [22:31:02 CEST] <kepstin> Thomas_J: according to the output you pasted earlier, your ffmpeg definitely supports alsa input [22:31:40 CEST] <another> the readme also says that it was built with alsa [22:32:08 CEST] <Thomas_J> I don't know but the ffmpeg docs show that the -enable-libalsa has to be used to activate it. [22:32:21 CEST] <furq> where does it say that [22:32:52 CEST] <furq> there is no such option in configure, the only option is --disable-alsa [22:32:56 CEST] <another> that's true, if you want to be sure that support is built-in [22:33:07 CEST] <furq> it'll be automatically enabled if you have libasound installed when you run configure [22:33:07 CEST] <kepstin> note that another way to check if something is enabled in your ffmpeg is the builtin help - e.g. "ffmpeg -devices" will show a D and/or E, and "ffmpeg -h demuxer=alsa" will show a list of options. [22:33:14 CEST] <another> but there are defaults in configure [22:33:40 CEST] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/configure#L203 [22:34:07 CEST] <another> what furq said [22:36:28 CEST] <Thomas_J> To enable this input device during configuration you need libasound installed on your system. https://www.ffmpeg.org/ffmpeg-devices.html#alsa [22:36:47 CEST] <Thomas_J> Sorry, the library is libasound. [22:37:15 CEST] <furq> right [22:37:17 CEST] <furq> that's auto-enabled [22:37:26 CEST] <furq> the configuration string ffmpeg prints is literally just the string that you ran configure with [22:37:38 CEST] <Thomas_J> Okay, I was reading that as libsound enabled. [22:38:27 CEST] <Thomas_J> This is a prebuilt binary [22:38:35 CEST] <furq> you = whoever built the binary [22:39:03 CEST] <kepstin> (as an unrelated aside, I find it really amusing that prores is 'DEVIL.' and jpeg2000 is 'DEVILS' in the ffmpeg -codecs output) [22:39:31 CEST] <Thomas_J> I have alsa working on my system. I need to check for the libasound lib. [22:39:42 CEST] <another> other codecs are devils as well ;) [22:39:42 CEST] <furq> if you have alsa then you have libasound [22:39:45 CEST] <Thomas_J> Correct? [22:40:55 CEST] <furq> as other people said just run ffmpeg -devices and see if alsa is in there [22:41:01 CEST] <Thomas_J> You would think so. forcing alsa, why is it looking for pulseaudio? [22:41:27 CEST] <Thomas_J> I forgot about that. [22:42:34 CEST] <Thomas_J> DE alsa ALSA audio output [22:42:38 CEST] <kepstin> your alsa configuration is attempting to load the pulseaudio plugin, but that plugin isn't installed [22:42:49 CEST] <Thomas_J> I need input. [22:42:55 CEST] <furq> if you have pulse installed then you should probably just use the pulse input [22:43:33 CEST] <furq> nvm those static builds apparently don't have it [22:44:13 CEST] <Thomas_J> I have pulseaudio installed on the system. [22:45:26 CEST] <kepstin> I wouldn't be surprised if the pulse library has some issues with static linking. [22:45:39 CEST] <Thomas_J> Shouldn't ffmpeg be able to find the system modules? [22:46:16 CEST] <kepstin> ffmpeg supports the stuff that was enabled when it was compiled. it can't magically gain support for new things at runtime. [22:46:18 CEST] <Thomas_J> Ohhh, Lightbulb turned on. it's a static build! [22:46:40 CEST] <kepstin> that would be true even if it wasn't a static build [22:48:02 CEST] <Thomas_J> Isn't that the point to dynamic builds is that it will locate the modules it needs at runtime and link them in? [22:48:43 CEST] <pink_mist> not even remotely [22:48:44 CEST] <kepstin> no, the point of dynamic builds is that a shared copy of the library from the system can be used rather than making a duplicate copy in apps, saving disk space and in some cases memory. [22:49:02 CEST] <kepstin> (also, system libraries can be updated independently, if compatible) [22:49:53 CEST] <kepstin> to do something where you add new functionality at runtime, you need to build a runtime loading plugin system, like e.g. gstreamer has [22:54:35 CEST] <Thomas_J> Anyway, I need to recompile because the static build doesn't have what I need compiled into it. Correct? [22:55:42 CEST] <kepstin> if you want to use pulseaudio, then yes. If you don't want to do that, you might be able to stop or suspend pulseaudio to use also devices. [23:17:25 CEST] <Thomas_J> I'm missing alsa-lib. I am looking for it. If it was supposed to come with libasound, I don't have it. [23:35:29 CEST] <Thomas_J> I reinstalled libasound2 but I still do not have the /usr/lib/alsa-lib subdirectory for which ffmpeg is trying to search. Do you think that If I recompile ffmpeg that it will stop looking for that directory that libasound2 obviously no longer uses. [23:38:32 CEST] <nine_milli_> blb_ [23:40:11 CEST] <nine_milli_> can yall give me some tips covering a directory full of jpegs to a video using as little cpu as possible libvpx [23:42:40 CEST] <kepstin> nine_milli_: not sure what you mean "as little cpu as possible". normally you want it to use all available cpu power so it goes as fast as possible. [23:43:13 CEST] <nine_milli_> i want the opposite [23:43:28 CEST] <nine_milli_> dont care how long it takes dont want to effecty other threads [23:43:39 CEST] <Thomas_J> Are the packages on ffmpeg.org/downloads updated with the rtmps fix yet? [23:43:42 CEST] <kepstin> running libvpx with the defaults should do that fine then, it runs single-threaded by default [23:44:38 CEST] <kepstin> other than that, you'd have to use external scheduling tools to e.g. lower process priority [23:45:38 CEST] <nine_milli_> well im talking android running as a .so [23:46:02 CEST] <nine_milli_> i am doing setpiority 18 on the thread just wanted to know if there's anything else i can do [23:47:40 CEST] <nine_milli_> would it help if i did only a few jpegs at a time? [23:49:28 CEST] <kepstin> if ffmpeg's running faster than realtime, you could slow it down by using the "-re" input option to add some sleeps in the input reading between frames. [23:49:58 CEST] <nine_milli_> let me look into that thanks [23:50:20 CEST] <kepstin> other than that i'm not really sure how you'd throttle it. You could always send SIGSTOP/SIGCONT periodically i guess? [23:51:11 CEST] <kepstin> that would mostly be useful if you want to keep the device cool by inserting idle time, rather than preventing it from interfering with other apps [00:00:00 CEST] --- Thu Jul 11 2019

1 0

ffmpeg-devel.log.20190709
by burek 10 Jul '19

10 Jul '19

[00:05:35 CEST] <juandl__> Hello everyone,my name is Juan. I'm working on a change to extract QP from different encoded streams, It'd be great if anyone could give me some feedback about my design. https://docs.google.com/document/d/1WClt3EqhjwdGXhEw386O0wfn3IBQ1Ib-_5emVM1… [00:08:44 CEST] <juandl__> feel free to comment on the doc [00:09:58 CEST] <Lynne> nice design document, would discuss in a meeting/10, but you can already do this with the region of interest api [00:10:20 CEST] <tmm1> has anyone heard of h264_nvenc not respecting -b:v/-maxrate ? [00:14:38 CEST] <jkqxz> What do you want to do with the QPs once you've extracted them? [00:16:51 CEST] <tmm1> this seems strange.. why would nvenc_setup_encoder() be overwriting avctx->bit_rate (https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L1229-L1230) [00:22:34 CEST] <cone-618> ffmpeg 03Andreas Rheinhardt 07master:730e5be3aa11: cbs: ff_cbs_delete_unit: Replace return value with assert [00:22:35 CEST] <cone-618> ffmpeg 03Andreas Rheinhardt 07master:d9418aba66e7: cbs_h264, h264_metadata: Deleting SEI messages never fails [00:22:36 CEST] <cone-618> ffmpeg 03Andreas Rheinhardt 07master:f83b46e2181c: configure, cbs_h2645: Remove unneeded golomb dependency [00:27:16 CEST] <mkver> jkqxz: Any decision on whether to make updating the AVCodecParameters mandatory? [00:28:45 CEST] <mkver> (Honestly, I am surprised that I can't find a concrete example for the abstract "The bistream might not be able to express everything" situation.) [00:29:44 CEST] <juandl__> jkqxz, it is for quality metrics mostly, it could help my team adjust rate control if they have more information about QPs per frame [00:31:13 CEST] <jkqxz> mkver: I'm inclined to agree with jamrial that it should be mandatory, but I don't have a strong opinion. [00:31:30 CEST] <mkver> Ok, then I will adapt the patchset. [00:31:42 CEST] <jkqxz> (Hence my looking for examples.) [00:31:43 CEST] <mkver> And did you overlook this: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245054.html? [00:31:59 CEST] <jkqxz> Yes. [00:32:45 CEST] <jkqxz> I still have 20+ on the big patchset; anything else I should look at? [00:33:59 CEST] <mkver> 20+ on the (my) big patchset left? No. [00:34:14 CEST] <Lynne> juandl__: you ought to use an analyzer, there's a few out there [00:34:16 CEST] <mkver> It's just 12. [00:35:39 CEST] <jkqxz> I mean 20-31 of 31. [00:36:05 CEST] <jkqxz> Well, not yet if you send new ones. [00:38:19 CEST] <jkqxz> juandl__: QP is not a very good measure to use to asssess quality after the fact. It is a sensible to use it with an encoder as an indication of the intended result, but given an encoded stream there are a lot of other things which change the result. [00:39:05 CEST] <jkqxz> Encoding at minimum QP doesn't help you if you throw away all the AC coefficients. [00:40:39 CEST] <mkver> There is btw also a patch from James https://ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245643.html. [00:41:51 CEST] <mkver> He even wants to stop using h2645_parse functions, because currently everything not in the base layer gets dropped by hevc_parse_nal_header. [00:42:27 CEST] <jkqxz> He said he would revise it, so I didn't comment. [00:43:01 CEST] <mkver> And of course there are the vp9_raw_reorder patches that I sent you. [00:45:18 CEST] <jkqxz> Rewriting to avoid the h2645_parse functions seems reasonable to me. I guess you'd want to preserve the current performance levels, though? That doesn't sound so fun. [00:47:17 CEST] <mkver> Couldn't this be changed by simply adding a new parameter to ff_h2645_packet_split and hevc_parse_nal_header? [00:48:01 CEST] <mkver> (And actually I want to improve the performance: ff_h2645_extract_rbsp uses suboptimal masks.) [00:49:40 CEST] <juandl__> jkqxz Lynne: thanks for the advice, we specifically need FFmpeg for one of the internal analyzing tools. I'd appreciate any more feedback on the data structure or the implementation. Thanks! [00:51:32 CEST] <kierank> I thought we already had a qp extraction api [00:52:21 CEST] <mkver> jkqxz: Btw: This commit https://github.com/mkver/FFmpeg/commit/a40d9bc8d5fb11f161b2f29ffd1bded51461… improves the speed of h264_metadata by more than 50% for me. [04:07:00 CEST] <_orestes_> Hi All! I am trying to get hardware encoding working on a raspi 4. I can get it to use the hardware but the SPS and PPS are not sent except right at the start. I found that that setting "OMX_IndexParamBrcmVideoAVCSEIEnable" is a common answer. there is nothing i can find though on WHERE to set that. has anyone done this? [08:13:25 CEST] <Compn> always with the rasbpi people [11:50:31 CEST] <durandal_1707> nothing left to do [11:57:09 CEST] <kierank> durandal_1707: cfhd p-frames [11:57:22 CEST] <kierank> durandal_1707: also liking my tweets [11:58:22 CEST] <durandal_1707> kierank: no real samples, i'm stuck [11:58:32 CEST] <kierank> what's wrong with mountain sample [11:58:35 CEST] <kierank> why can it not be fixed [11:59:00 CEST] <durandal_1707> i need real sample [12:00:10 CEST] <durandal_1707> one where more frames are P frames [12:23:00 CEST] <mkver> durandal_1707: You could also take at this patchset for truehd_core: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-July/246230.html [12:29:27 CEST] <durandal_1707> mkver: if it works just apply it! [12:29:43 CEST] <mkver> I don't have commit rights. [12:29:51 CEST] <durandal_1707> get one [12:30:08 CEST] <mkver> Also, shouldn't patches always be reviewed even when the author has commit rights? [12:30:13 CEST] <durandal_1707> which matroskadec patches are not applied? [12:30:24 CEST] <durandal_1707> mkver: nope [12:31:01 CEST] <mkver> Everything from 17 onwards in this patchset: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244193.html [12:31:22 CEST] <JEEB> they should, but in some cases E_NOBODY_CARES in which case if you have FATE coverage added or existent then if you are confident it could start going in [12:31:53 CEST] <JEEB> last time I pushed something nobody seemed to care about I gave it two weeks after my initial show of interest towards a patch (in this case I was not the original author) [12:32:16 CEST] <mkver> There is no fate coverage and if there were, I would need to change the fate output, given that it is explicitly intended to change the output. [12:33:41 CEST] <durandal_1707> i'm not matroska expert at all [12:34:32 CEST] <mkver> But I compared hashes of the output of our TrueHD decoder with a) after stripping Atmos away with my patchset applied b) after stripping Atmos away with current git head c) without stripping Atmos away. They were all equal. [12:35:46 CEST] <mkver> I also tested on a (non-Atmos capable) receiver. Everything worked fine. [12:37:34 CEST] <JEEB> would be nice to have a FATE test for that, but since that's a fixup instead of a new module I am definitely not requiring one :) [12:38:09 CEST] <JEEB> so the thing is that it copies the header, and then modifies some bits [12:38:50 CEST] <JEEB> and the bit mask has become smaller for what it copies over [12:39:08 CEST] <JEEB> 0x0f to 0x0c [12:39:18 CEST] <JEEB> (might take a look at that after $dayjob) [12:39:31 CEST] <JEEB> since it has a link to the spec [12:39:55 CEST] <mkver> That would be great. Thank you! [12:40:11 CEST] <JEEB> w/46 [12:59:18 CEST] <durandal_1707> mkver: have you checked that ordinary truehd streams still work? [12:59:31 CEST] <durandal_1707> when run with this bsf? [13:00:30 CEST] <mkver> They are not changed. [13:37:15 CEST] <durandal_1707> will apply truehd_core patches! [13:40:40 CEST] <mkver> Thanks! [13:47:14 CEST] <Lynne> "Intra-only frames in profile 0 are automatically BT.601" <- in vp9? what were google on? [13:52:45 CEST] <JEEB> Lynne: ahahah what [13:52:46 CEST] <JEEB> :D [13:55:12 CEST] <mkver> It's in vp9-bitstream-specification-v0.6-20160331-draft.pdf, pages 28-29. [14:00:09 CEST] <cone-688> ffmpeg 03Andreas Rheinhardt 07master:99c191151a71: truehd_core: Disable 16-channel presentation [14:00:09 CEST] <cone-688> ffmpeg 03Andreas Rheinhardt 07master:cbe23e40ae91: truehd_core: Correct output size [14:00:09 CEST] <cone-688> ffmpeg 03Andreas Rheinhardt 07master:610460a397b1: truehd_core: Return error in case of error [14:00:09 CEST] <cone-688> ffmpeg 03Andreas Rheinhardt 07master:2275e70569ce: truehd_core: Miscellaneous improvements [14:00:09 CEST] <cone-688> ffmpeg 03Andreas Rheinhardt 07master:836065b27a0f: truehd_core: Use byte offsets instead of bit offsets [14:00:09 CEST] <cone-688> ffmpeg 03Andreas Rheinhardt 07master:5a481b15bd86: truehd_core: Switch to in-place modifications [14:01:02 CEST] <Lynne> that looks like 100% leftover from when vp8 got support for !bt.601 and makes intra-only frames completely useless as everything is bt709 these days [14:03:29 CEST] <Lynne> I have 0 idea what they were meant to be used as though [14:04:04 CEST] <Lynne> they can be put in as random I-frames but they're required not to reset decoding so I don't think they can be used as a reference [14:11:13 CEST] <mkver> They can be used as reference; that's why they contain the refresh_frame_flags element. [14:25:33 CEST] <cehoyos> Does really everybody believe that side data is the best solution for tiles? [14:26:12 CEST] <durandal_1707> its format is not well designed for ffmpeg [14:26:13 CEST] <JEEB> at this point that is the only alternative that I have heard of that can be implemented somehow. if you have another idea please feel free to explain :) [14:27:41 CEST] <Lynne> side data is the best way to make it fit [14:28:33 CEST] <Lynne> mkver: in that case it was probably meant to be used to fix horrid rate control undershoots [14:28:33 CEST] <cehoyos> I believe there is a solution that makes user's lifes much easier [14:28:57 CEST] <cehoyos> I wonder if side data has any advantage: [14:29:12 CEST] <cehoyos> Do we want to support remuxing of heif images? Would this have any usecase? [14:29:25 CEST] <JEEB> basically how I understand the side data alternative is to keep the decoder buffer the images [14:29:36 CEST] <cehoyos> Or the demuxer... [14:29:37 CEST] <JEEB> until all tiles have been received [14:29:57 CEST] <JEEB> well, whatever layer makes sense? [14:30:16 CEST] <JEEB> but the tiles are usually separate images so I would expect them to go around as compressed data as such [14:30:31 CEST] <JEEB> unless you want to have separate buffers in an AVPacket or something like that (for example) [14:30:32 CEST] <cehoyos> Note we have an open ticket since forever with the same issue (searching...) [14:30:58 CEST] <JEEB> and then of course the muxer would take in this data as well [14:31:14 CEST] <JEEB> but I would consider remux t obe a separate task from enabling decoding [14:31:28 CEST] <JEEB> but the overarching design should be capable of handling both [14:31:34 CEST] <cehoyos> https://trac.ffmpeg.org/ticket/2564 [14:31:35 CEST] <Lynne> I don't think there's a use case for remuxing heif, since only heif supports the tiling used [14:31:47 CEST] <JEEB> Lynne: remuxing HEIF to HEIF in my mind [14:31:50 CEST] <JEEB> not remuxing out of it [14:32:06 CEST] <cehoyos> Then why shouldn't the heif demuxer return (large) rawvideo frames? [14:32:07 CEST] <JEEB> or well, you can remux to mp4 but it will be separate images then :P [14:32:14 CEST] <Lynne> yeah, and that's kinda pointless unless stripping thumbnails or such [14:32:28 CEST] <JEEB> cehoyos: and you lose all visibility of the compressed data then? [14:32:40 CEST] <cehoyos> Again: What is the usecase? [14:32:54 CEST] <durandal_1707> what is heif usecase? [14:33:03 CEST] <cehoyos> (Apart from offering a flag to return the compressed data) [14:33:17 CEST] <cehoyos> I still believe we work on a Swiss knife... [14:33:56 CEST] <JEEB> remux of HEIF and TIFF with tiles is IMHO not too shabby of an idea. but yes, we should also support outputting the full image after decoding. which is as far as I currently understand the side data pops up [14:34:07 CEST] <JEEB> of course for remux AVPackets would have to have stuff as well [14:34:17 CEST] <JEEB> so that the muxer could know if it's being fed a tile or not [14:34:17 CEST] <cehoyos> The issue is not that I believe the side data would somehow be "wrong", I just believe another solution that makes using heif from libav* much easier exists [14:34:25 CEST] <durandal_1707> cehoyos: more swiss cheese with bunch of holes [14:34:41 CEST] <JEEB> please keep civil, the discussion is just OK so far durandal_1707 :) [14:35:01 CEST] <cehoyos> I did not consider Paul's comment in any way uncivil [14:35:10 CEST] <JEEB> ok [14:35:31 CEST] <JEEB> anyways, I don't disagree that there couldn't be other ways of handling things [14:35:36 CEST] <cehoyos> But I wonder now if I understand correctly that you are arguing we have to provide the compressed data by default because remuxing is an important usecase? [14:35:55 CEST] <JEEB> no, I think it comes from the lavf/lavc design more tan that [14:36:01 CEST] <JEEB> lavf gives you demuxed packets [14:36:05 CEST] <JEEB> lavc gives you decoded stuff out [14:36:26 CEST] <cehoyos> But this concept exists to make user's lifes easier, not because it is some ancient law, no? [14:36:41 CEST] <cehoyos> And in this case, I thought we agree that there is not usecase. [14:36:44 CEST] <durandal_1707> how are tiles stored in HEIF? [14:36:50 CEST] <JEEB> separate packets [14:36:54 CEST] <JEEB> not tiled HEVC [14:37:02 CEST] <JEEB> if it was just tiled HEVC it would be simpler :P [14:37:21 CEST] <cehoyos> (And I wonder where your argument was when this f* raw network codec was committed without resistance= [14:37:40 CEST] <cehoyos> ) [14:37:56 CEST] <durandal_1707> then demux all relevant packets into one uber defined format and let hevc handle it? [14:38:08 CEST] <JEEB> durandal_1707: that is another option I mentioned [14:38:15 CEST] <Lynne> that's no good [14:38:17 CEST] <JEEB> have a packet with multiple buffers or whatever [14:38:17 CEST] <cehoyos> As in: Inventing in our own variant of hevc? [14:38:22 CEST] <JEEB> cehoyos: no [14:38:24 CEST] <Lynne> we shouldn't invent our own packing formats for packets [14:38:32 CEST] <Lynne> packets should be standard [14:38:45 CEST] <JEEB> Lynne: no, the packets should be standard, just more than one buffer in a packet. [14:38:45 CEST] <cehoyos> My question was if this was the suggestion, and I believe the answer is "yes" [14:39:01 CEST] <durandal_1707> then invent bsf for HEIF ? [14:39:03 CEST] <Lynne> that's the benefit of side data, it keeps packets untouched, standard hevc packets [14:39:08 CEST] <JEEB> > into one uber defined format [14:39:14 CEST] <cehoyos> But how is that a benefit? [14:39:17 CEST] <JEEB> I understood that as multiple buffers somehow put into an AVPacket [14:39:23 CEST] <JEEB> not somehow modifying the data [14:39:29 CEST] <Lynne> yes, that's the idea, let a bsf take packets and reconstruct a single packet based on the side data [14:39:29 CEST] <JEEB> a BSF is another alternative, maybe [14:39:43 CEST] <Lynne> or if not, let the decoder tile them [14:39:54 CEST] <cehoyos> And the output of the bsf would not be a variant of heif invented by us? [14:39:59 CEST] <JEEB> no [14:40:04 CEST] <JEEB> it would be standard tiled HEVC [14:40:07 CEST] <cehoyos> But what would it be? [14:40:09 CEST] <JEEB> the problem is, if that is possible [14:40:19 CEST] <cehoyos> Does our decoder support tiled hevc? [14:40:22 CEST] <JEEB> which is why it isn't being raised as the most possible alternative [14:40:22 CEST] <cehoyos> Do we have a sample? [14:40:40 CEST] <JEEB> I think the standard set has tiled HEVC, but I must be honest and say that I have not checked :P [14:40:41 CEST] <kurosu> iirc, heif "tracks" may contain independant images or actual tiles (as internal subdivision of the same image) [14:40:49 CEST] <Lynne> yes, it supports it, it will even do slice threading for those [14:41:40 CEST] <cehoyos> Atm, the student has the issue that he creates a stream with a single frame for each tile [14:42:08 CEST] <durandal_1707> cool, export sidedata for xstack filter then? [14:42:13 CEST] <cehoyos> But at some point, he will hopefully solve this and I sincerely hope side-data (that would make using the demuxer unlikely) can be avoided. [14:42:38 CEST] <cehoyos> Yes, but are we sure that the tiles alway have sane sizes with respect to each other? [14:42:39 CEST] <JEEB> how would it become unlikley since most users will likely want to utilize the decoder together with it? [14:42:55 CEST] <JEEB> since my understand ing was that the decoder would utilize the side data? [14:42:56 CEST] <durandal_1707> it is joke [14:43:04 CEST] <cehoyos> Most user's of FFmpeg (the ones that are not active here) likely have never heard of FFmpeg side-data [14:43:20 CEST] <JEEB> if you don't need to touch it, then how does that exactly affect an API user? [14:43:31 CEST] <cehoyos> I thought this would be the application's job, did I misunderstand? [14:43:39 CEST] <JEEB> I might be misundersatnding as well [14:44:08 CEST] <cehoyos> So instead of using my "hack" that only affects one library, your suggestion is to put special-case code in all the libraries? [14:44:15 CEST] <JEEB> ?! [14:44:23 CEST] <cehoyos> ? [14:44:51 CEST] <JEEB> I'm kind of struggling to understand since what I rmember being the discussion here is that the decoder would read the side data and buffer according and push out the full image [14:44:58 CEST] <JEEB> I might be incorrect with this so feel free to correct [14:45:04 CEST] <JEEB> and I am not sure how much of this is a hack? [14:45:15 CEST] <JEEB> of course if you consider side data altogether to be a hack then sure [14:45:49 CEST] <cehoyos> Apart from the fact that - afaiu - this is not how lavc works so far, it would definitely (?) include a special case in lavf (create specific side data for tiles) and lavc (read the side data, reserve image space, wait for more frames, output in the future) [14:46:22 CEST] <JEEB> special cases aka ifs, most probably yes [14:46:35 CEST] <JEEB> I am not sure how different this is wrt to how lavf/lavc works currently [14:46:46 CEST] <cehoyos> (I feared "side data" would mean to inform the application it will have to insert a filter chain to get the intended output but apparently I was wrong as I learned now) [14:47:00 CEST] <JEEB> wel, this is just what I read here some days/weeks ago [14:47:04 CEST] <JEEB> might hav ebeen different on the ML [14:47:21 CEST] <JEEB> but that way you keep the separation of coded packets in lavf, and lavc would give the API user something it would expect [14:47:23 CEST] <cehoyos> I don't think there was much on the ml [14:47:53 CEST] <cehoyos> The user expects to send 16 frames to get one output frame? [14:47:58 CEST] <cehoyos> possibly... [14:48:30 CEST] <Lynne> cehoyos: I'll nak an attempt to make the demuxer do the decoding and output rawframes, that's by far the worst option [14:48:49 CEST] <cehoyos> That's great given your commit history, lol [14:49:12 CEST] <Lynne> lol [14:49:51 CEST] <cehoyos> As in: We must really not try to ease user's lifes? [14:50:08 CEST] <Lynne> yes, we need the decoder to decode packets and demuxers to output packets [14:50:24 CEST] <durandal_1707> Lynne: but that is most clean solution! [14:50:32 CEST] <Lynne> if users need an easier life they'd use ffms2 [14:50:33 CEST] <cehoyos> Yes, please play the sample of above ticket to see how useful this is [14:51:24 CEST] <JEEB> the only non-easy part is having to feed the decoder more. and in that case our normal enc/dec APIs can return "please feed more" [14:51:35 CEST] <JEEB> I think by now the feed/receive APIs are a few years old [14:51:54 CEST] <JEEB> and the older API had the frame received flag as well I think? [14:52:06 CEST] <cehoyos> So what you are suggesting is to put the "hack" that I suggested to have in libavformat in libavcodec and suddenly it is not a "hack"? [14:52:29 CEST] <JEEB> I am not seeing the clear improvement in doing decoding in lavf [14:52:31 CEST] <Lynne> yes, because there's nothing hacky about letting lavc do what its meant to do - decode [14:52:56 CEST] <cehoyos> This isn't about decoding, please try for a moment to understand what you are suggesting [14:53:05 CEST] <durandal_1707> one packet would got side-data with more packets? [14:53:12 CEST] <JEEB> durandal_1707: no [14:53:31 CEST] <cehoyos> The exact code that you don't want to see in lavf would have to be put in lavc (or the hevc decoder) - in addition to the special code in lavc only used for three tiled formats [14:54:17 CEST] <Lynne> yes, that's okay, tiling in the decoder is simpler and more efficient, since you can just alloc a single frame and decode directly to it [14:54:37 CEST] <Lynne> while using the decoder api in the demuxer is completely nuts [14:55:14 CEST] <cehoyos> So back to one of my questions above: What do we know about the tiles in general? [14:55:41 CEST] <cehoyos> (Isn't it more nuts to keep invalid code?) [14:55:50 CEST] <JEEB> invalid code? [14:56:00 CEST] <cehoyos> unrelated to heif... [14:56:08 CEST] <JEEB> ok [14:56:27 CEST] <cehoyos> I still believe personal attacks are acceptable to some degree [14:56:53 CEST] <JEEB> also yes, our knowledge of the tiles is important enough. we have to be able to signal the tiles and if there are tiles missing we should be able to start decoding the following one [14:57:05 CEST] <durandal_1707> you want to personally attack someone here? [14:57:12 CEST] <JEEB> (although that could be also done through checking if we had already decoded a tile for the currently decoded frame) [14:57:21 CEST] <JEEB> anyways, sorry - need to go back to healing myself [14:57:21 CEST] <cehoyos> No, I only meant I can stand some of them, like the one above [14:57:29 CEST] <cehoyos> What happened? [14:57:59 CEST] <durandal_1707> he need to heal after being attacked :) [14:58:10 CEST] <cehoyos> ;-) [14:58:26 CEST] <JEEB> w/29 [14:59:13 CEST] <cehoyos> https://de.wikipedia.org/wiki/Mercedes-Benz_W_29 [15:01:03 CEST] <Lynne> cehoyos: if anything I was being attacked for my #commits [15:01:59 CEST] <cehoyos> Technical arguments instead of threats may help=-) [15:02:21 CEST] <Lynne> nuts is a valid technical argument and a reaction for using lavc api inside lavf [15:02:37 CEST] <Lynne> unacceptable is also acceptable [15:04:08 CEST] <cehoyos> Yes, I am sure there is a dimension where "nuts" is a technical argument! [15:04:28 CEST] <durandal_1707> just decode single tile, and declare heif broken nuts format! [15:05:18 CEST] <cehoyos> https://en.wikipedia.org/wiki/Socket_wrench [15:05:24 CEST] <cehoyos> Found it! [15:13:27 CEST] <durandal_1707> cehoyos: what you gonna talk about at next nttw conference? [15:13:57 CEST] <kierank> durandal_1707: i'll go if you will be there [15:16:43 CEST] <kierank> jamrial: heh you missed lots of stuff [15:16:59 CEST] <kierank> probably a good thing [15:17:17 CEST] <jamrial> oh boy :p [15:18:20 CEST] <jamrial> send me a log? or i can wait until the evening for it to show up on pipermail [15:21:12 CEST] <cehoyos> durandal_1707: Didn't you see the sheet? I will repeat the last talk plus updates [15:21:20 CEST] <cehoyos> (If they want it) [15:22:51 CEST] <durandal_1707> cehoyos: i looked at sheet, but what updates you will tell them? nothing new here happened [15:22:58 CEST] <kurosu> I also skipped a lot of the heif discussion, but I surmise it will impact avif handling ? [15:23:59 CEST] <cehoyos> I misunderstood the "side data" suggestion, assuming that special code in the decoder to delay output and create special frames would not be more acceptable than lavf outputting rawvideo [15:24:14 CEST] <cehoyos> (I thought the side data would go to the calling application, not lavc) [15:24:42 CEST] <cehoyos> vc1 is now bit-exact (for the known samples), I consider this a major improvement [15:26:04 CEST] <cehoyos> The second suggestion are comments regarding a talk two years ago "don't use lossless encryption for archiving, there is good lossy compression" and last years answer. [15:26:47 CEST] <durandal_1707> huh, drop that, they need bitexact video for every frame [15:27:00 CEST] <cehoyos> I should drop my comments? [15:27:28 CEST] <durandal_1707> comment about telling them to use lossy compression instead [15:27:49 CEST] <cehoyos> I should comment and tell them to use lossy compression? [15:28:12 CEST] <durandal_1707> dunno, there was some talks about that but forgot details [15:30:28 CEST] <cehoyos> I'll try again: There was a talk two years ago in Vienna that consisted of suggestions not to use lossless compression, and last year in London there was an answer. I wondered if more comments may make sense, especially telling the community if all their digital video is one type of compressed format, re-compressing it in lossless format will not help, while using ffv1 (or j2k) for their scans is useful [15:32:55 CEST] <durandal_1707> aha, i will try not to forget [15:38:09 CEST] <nevcairiel> Didn't we already agree on a perfectly clear, scalable and portable HEIF solution a few days ago, by letting each component do exactly what its designed to do, leverage every component clearnly and without hacks? [15:41:46 CEST] <nevcairiel> no bsf, no hacks in the demuxer or decoder, just flat out demuxing, decoding, and tiles being assembled in avfilter, since thats the component we have to deal with raw images [15:42:06 CEST] <durandal_1707> ugh, nope [15:43:15 CEST] <nevcairiel> no other solution will ever let you do it properly, so, yes. [15:45:00 CEST] <nevcairiel> Especially if you want to involve hwaccel, any such "hacks" will either make it impossible or make them extremely more hacky [15:47:39 CEST] <Lynne> nevcairiel: well, that's kinda still your idea [15:48:22 CEST] <Lynne> it'll be difficult to deal with hwframes in lavfi anyway to stitch them together [15:49:06 CEST] <Lynne> since you'll need to use a different filter with a different name and it'll involve a copy, and then there's still the issue with the frame size > capabilities [15:50:00 CEST] <Lynne> you still need packet side data either way, which will have to be converted to frame side data for your approach, so its a good starting point [15:59:16 CEST] <nevcairiel> the side data conversion is not something you need, thats something the framework already does [15:59:42 CEST] <nevcairiel> and a hwaccel stitching filter is at least a possibility in that design, unlike any other [16:00:10 CEST] <nevcairiel> and a bsf will cause images to become too large for hwaccel quickly [16:00:20 CEST] <durandal_1707> who shares irc logs in real-time with other people? [16:00:57 CEST] <nevcairiel> like, a 4K capable hw decoder is easily defeated by a modern camera [16:06:33 CEST] <durandal_1707> if you do not start answering, i will start banning random no-op on this channel! [16:28:13 CEST] <Lynne> nevcairiel: if users require hw decoding throughout they could strip the side data and do the tiling themselves (or set up an overlay filter) [16:29:11 CEST] <philipl> the side-data stiching filter approach would require a separate filter for each hwaccel interop system, but we have families of filters for things like scaling already. [16:29:18 CEST] <philipl> That part isn't particularly unusual. [16:45:42 CEST] <cehoyos> Good to know that I did understand it correctly! [16:45:58 CEST] <cehoyos> Well, other suggestions exist. [16:53:15 CEST] <nevcairiel> Lynne: its 2019, hw decoding needs to be a primary concern in any such design, not some afterthought that people are expected to hack together manually [16:53:44 CEST] <cehoyos> But isn't hw decoding completely irrelevant for heif? [16:54:07 CEST] <nevcairiel> why? because its only one image? I'm sure people would be happy if that loads faster too [16:54:50 CEST] <cehoyos> If it came for free - ok, but if it comes with a huge amount of necessary special code, I am 100% nobody cares about the speed. [16:55:02 CEST] <cehoyos> (My suggestion is to offer both possibilities anyway) [16:55:03 CEST] <nevcairiel> thats why we need to make it free [16:55:24 CEST] <nevcairiel> and not design some method that requires a lot of manual labor to make it hw capable [16:55:33 CEST] <cehoyos> But it isn't in your suggestion, and the others (except you) didn't even understand that this is what you suggested [16:55:51 CEST] <cehoyos> Why should it be hw-capable? [16:56:05 CEST] <nevcairiel> Why shouldn't it? [16:56:19 CEST] <nevcairiel> because its "easier"? [16:56:21 CEST] <nevcairiel> thats just lazy : ) [16:56:26 CEST] <cehoyos> Because for all users except you this means additional work that they don't even know about [16:56:34 CEST] <cehoyos> lazy by whom? [16:56:54 CEST] <nevcairiel> whoever is suggesting a method to handle heif without accounting for hw decoding [16:56:55 CEST] <cehoyos> It is lazy to put the burden downstream instead of finding a soluation that produces one frame for a fringe format [16:57:30 CEST] <nevcairiel> Is every photo taking with a modern iPhone that fringe? [16:57:51 CEST] <cehoyos> It doesn't need hardware acceleration, it needs an out-of-the-box solution [16:59:40 CEST] <nevcairiel> if you want something that just spits out image data, then libav* libraries are too low-level anyway and you probably want gstreamer or something like that, so we might as well design it properly without breaking library borders left and right [17:00:01 CEST] <cehoyos> So the users of libav* should install gstreamer for heif? [17:00:15 CEST] <cehoyos> and swf [17:00:18 CEST] <kierank> yes or libav* should have something like that [17:00:31 CEST] <kierank> media has evolved beyond an api from 2002 [17:00:44 CEST] <nevcairiel> if they can't deal with a new API to handle tiled images, then yes, they should [17:01:04 CEST] <nevcairiel> and i'm not proposing to make it incredibly hard, piping your image through lavfi for example isn't exactly rocket science [17:01:07 CEST] <cehoyos> But why on earth should they? It's not that a 90 minute video has to be decoded [17:01:32 CEST] <nevcairiel> Independent of hw decoding, those proposed solutions are giant hacks and not acceptable [17:02:45 CEST] <nevcairiel> stuff i read earlier had me almost throw up, having the demuxer hand out raw decoded image data? seriously? [17:02:57 CEST] <cehoyos> At least I am not alone [17:03:23 CEST] <nevcairiel> the bsf approach might be ok-ish if it works [17:03:35 CEST] <nevcairiel> but i'm skeptical of that, personally [17:03:36 CEST] <cehoyos> Too good to be true [17:06:07 CEST] <nevcairiel> so in my mind that leaves the simple solution of just decoding the tiles one by one and stiching them together after decoding, and the perfect place for such a stiching filter is avfilter. ffmpeg.c could auto-insert the filter even. for API users that don't use avfilter yet, they would have to work on doing that. [17:06:52 CEST] <nevcairiel> as a bonus, this method could support full hwaccel - if someone were to write a stiching filter, or with download. [17:11:03 CEST] <durandal_1707> stiching what? [17:23:37 CEST] <durandal_1707> nothing left to do :( [17:30:42 CEST] <philipl> The whole reason why the tiling exists is *because* of hw decoders and ther comparatively low size limits. It would be ironic if we came up with an approach to tiling that prevented hwaccel from working. [17:35:42 CEST] <Lynne> have the texture limits (for vulkan etc.) jumped up or are they still 8kx8k? [17:36:17 CEST] <nevcairiel> well desktop decoders have relatively higher limits then mobile decoders, so its probably not that extremely bad, many desktop decoders can do 8k hevc decoding [17:36:42 CEST] <nevcairiel> but you can still come up with an image that would exceed that of course [17:37:18 CEST] <philipl> My nvidia desktop card has 8k hevc limits and 32k vulkan image dimension limits. [17:37:43 CEST] <philipl> But there's plenty of >8k cameras out there. [17:39:05 CEST] <philipl> Lynne: (but there's a fair point there that in some situations, stiching might have to be deferred all the way to geometry in the renderer if the texture limit is exceeded) [17:40:20 CEST] <nevcairiel> you might also pre-scale the tiles if you know how its likely going to be shown [17:40:37 CEST] <nevcairiel> although without overlap that might not be ideal [18:03:29 CEST] <durandal_1707> have ideas for a/v filter? [18:07:04 CEST] <Lynne> rnnoise [18:09:15 CEST] <durandal_1707> thats one for you [18:11:22 CEST] <durandal_1707> Lynne: what's delaying SIMD for tx? [18:15:50 CEST] <Lynne> the 8 point FFT simd crushed me [18:16:40 CEST] <Lynne> how can something be this simple and yet I can't beat the 20 instruction current version [18:17:20 CEST] <Lynne> the faster runtime, 1 less tmp reg and less rodata only kept my motivation that far [18:17:54 CEST] <Lynne> I've spent more time on a shenzhen io problem, I'll give it another go [18:19:15 CEST] <JEEB> time to make shenzhen IO mods out of multimedia optimization problems? [18:27:25 CEST] <Lynne> durandal_1707: if you're bored you could probably template libavutil/tx for int32/doubles [18:28:31 CEST] <Lynne> the mdct in the mp3 decoder could be replaced then since the C code is faster than a naive 320-point fft, even with simd [19:53:33 CEST] <DarkiJah> hello [19:58:32 CEST] <JEEB> ohai [00:00:00 CEST] --- Wed Jul 10 2019

1 0

ffmpeg.log.20190709
by burek 10 Jul '19

10 Jul '19

[00:24:58 CEST] <another> Thomas_J: add -v debug [01:30:51 CEST] <Thomas_J> -v debug is to verbose. It overruns my terminal. Too many lines of output. I will try to dump it to a file tomorrow. [01:33:57 CEST] <steve___> Thomas_J: use { command | command; } &> filename ## assuming you're using bash [01:34:55 CEST] <cehoyos> Thomas_J: First step to solve your issue is to test current FFmpeg instead of an eight-months old version [02:01:20 CEST] <furq> Thomas_J: just use -report [02:01:28 CEST] <furq> that saves the debug log to a file [02:19:46 CEST] <Thomas_J> <cehoyos> This is a version that was suggested to me yesterday by JEEB. Previously I was testing against new compilations of the latest stable version. They all had the same results. [02:32:03 CEST] <cehoyos> All I can tell you is that the old version has more bugs and less features, I have no idea why it would be recommended. [06:00:02 CEST] <MomokoGC> hello [06:00:23 CEST] <MomokoGC> i am trying to set a metadata tag called "ARTIST" [06:00:33 CEST] <MomokoGC> i do this -metadata ARTIST="%artist%" [06:01:00 CEST] <MomokoGC> but then somehow ffmpeg changes the tag from "ARTIST" to "Performer" [06:01:17 CEST] <MomokoGC> is there anyway i can get it to use the tag "ARTIST" only? [06:02:06 CEST] <MomokoGC> it's also changing "TITLE" to "Track name" :( [06:52:13 CEST] <MomokoGC> nvm i found another cli tool called tag to do it [12:37:27 CEST] <SoItBegins> I have an AVI file that has a VERY unusual video format. The format appears to be WRAW - a sequence of uncompressed .BMP images, I think? - and FFMPEG doesnt know how to handle it. Is there a way I can override FFMPEGs codec autodetection and get this video into a format that a modern video editor can read? [12:41:10 CEST] <durandal_1707> SoItBegins: try: ffmpeg -c:v bmp -i input.avi -f null - [12:42:23 CEST] <SoItBegins> Well, it didnt give me an error about not recognizing the codec, though it did say, Could not find codec parameters for stream 0 (Video: bmp, none, 256x192, 12609 kb/s): unspecified pixel format. [12:42:46 CEST] <SoItBegins> And then it stopped because, Too many packets buffered for output stream 0:1., which was the videos audio track. [12:42:53 CEST] <SoItBegins> (The audio track is plain old uncompressed audio.) [12:52:06 CEST] <SoItBegins> durandal_1707: Now how can I copy the video over to a new output file without FFMPEG recompressing it? [12:52:54 CEST] <dv_> hm I have an openmax based vp8 encoder here, and with it, you explicitely define whether or not the next frame shall be an alternate reference frame, golden frame, and whether or not that frame should be used for prediction [12:53:04 CEST] <dv_> my problem is - I have no idea when to enable these things [12:53:20 CEST] <dv_> I have no low-level encoding experience with vp8 [12:53:40 CEST] <dv_> is this even common? I thought typically people let libvpx decide when a golden frame and altref frames are generated [12:54:17 CEST] <JEEB> yes, generally the encoder has proper logic for frame type selection. it's nice if the API lets you override, but there should be a default [12:54:52 CEST] <JEEB> if it requires you to do all the heavy lifting then a) that's fun b) sounds like "we did not care too much about this" [12:55:48 CEST] <dv_> it starts at page 6 https://www.khronos.org/registry/OpenMAX-IL/extensions/KHR/OpenMAX_IL_1_1_2… [12:55:51 CEST] <durandal_1707> SoItBegins: please provide sample file if you can [12:56:11 CEST] <dv_> I suppose one way to go is to try to copy the logic that's in libvpx for this [12:56:26 CEST] <SoItBegins> durandal_1707: Uploading, hang on a minute [12:56:30 CEST] <durandal_1707> SoItBegins: you can copy but if it is not supported, it will still not work [12:57:11 CEST] <SoItBegins> durandal_1707: I was worried you might say something like that. In that case, my goal is to get the file from point A to point B with the least compression possible. [13:00:22 CEST] <durandal_1707> SoItBegins: ok, but first we need to make sure that it can be decoded [13:00:51 CEST] <SoItBegins> Well, I can open it with Quicktime Player, so its not garbage. The question then falls to, can ffmpeg decode it. [13:02:14 CEST] <durandal_1707> only if you provide actual file, without samples ffmpeg will never support it [13:02:44 CEST] <SoItBegins> Only 30 seconds to go on the upload. [13:02:59 CEST] <SoItBegins> Might not be BMP. FFMPEG gave error bad magic number'. [13:04:17 CEST] <SoItBegins> durandal_1707: Heres file: https://mega.nz/#!pY1WnQhC!eW3f2MzyAN4Pu4BDzPjCN7K9SVmY6szxuNWnD-3mnxs [13:05:34 CEST] <SoItBegins> Note that I might have to go to bed soon& [13:06:03 CEST] <SoItBegins> VLC, by the way, says the video is 32 bits RGB (RV32) [13:07:03 CEST] <durandal_1707> still downloading [13:09:47 CEST] <durandal_1707> SoItBegins: this is not BMP, it is just raw video [13:09:58 CEST] <durandal_1707> uncompessed [13:10:18 CEST] <SoItBegins> [nod] Im not surprised. This was converted from a kind of obscure video game format to AVI [13:10:34 CEST] <SoItBegins> What do I tell FFMPEG for video reading purposes? Can I convert it to .dv? [13:10:43 CEST] <durandal_1707> so make sure your ffmpeg is not too old [13:11:01 CEST] <durandal_1707> Stream #0:0: Video: rawvideo, bgra, 256x192, 12609 kb/s, 8 fps, 8 tbr, 8 tbn, 8 tbc [13:11:22 CEST] <SoItBegins> ffmpeg version 4.0.2 Copyright (c) 2000-2018 the FFmpeg developers [13:11:22 CEST] <SoItBegins> built with Apple LLVM version 9.0.0 (clang-900.0.39.2) [13:11:58 CEST] <SoItBegins> I tried ffmpeg -f rawvideo -i testopa2.avi testconv.mp4 but it gave me: [13:12:04 CEST] <SoItBegins> [IMGUTILS @ 0x7fff52e40208] Picture size 0x0 is invalid [13:12:55 CEST] <durandal_1707> SoItBegins: ffmpeg -i testopa2.avi testconv.mp4 [13:13:21 CEST] <durandal_1707> you should not override format like that [13:13:23 CEST] <SoItBegins> . . . . . . . . . . . . . . . now why didnt I try that to begin with? [13:14:18 CEST] <SoItBegins> durandal_1707: Littttle problem. Audio came through. Video didn't. [13:14:52 CEST] <SoItBegins> Its all black. [13:14:53 CEST] <durandal_1707> SoItBegins: use proper player and not quicktime [13:15:07 CEST] <durandal_1707> it is because its encoded as yuv444 [13:15:22 CEST] <SoItBegins> Ah. Well, see, the thing is, VLC can read it, but Im trying to import it into Camtasia [13:15:24 CEST] <durandal_1707> SoItBegins: ffmpeg -i testopa2.avi -pix_fmt yuv420p testconv.mp4 [13:15:26 CEST] <SoItBegins> for Mac [13:15:37 CEST] <SoItBegins> Which uses the Quicktime framework to import everything so... [13:16:42 CEST] <durandal_1707> force pix_fmt, see command above [13:16:52 CEST] <SoItBegins> durandal_1707: It works! [13:17:18 CEST] <SoItBegins> Last question: What video codec option will compress it as little as possible? (and still have it readable by Quicktime player and similar) [13:17:52 CEST] <durandal_1707> lossless, like lagarith/utvideo/magicyuv [13:18:08 CEST] <SoItBegins> All right. A big THANK YOU for all of your help! [13:22:29 CEST] <SoItBegins> durandal_1707: PS: Turns out the way I found that appears to be lossless (and is read by Camtasia) was to set FFMPEG to output the video as a .MOV with the codec being a PNG image sequence (!). [13:24:15 CEST] <durandal_1707> nice [13:43:59 CEST] <dv_> JEEB: do you know if the ffmpeg vp8 vaapi & v4l2enc based encoders too have to decide manually what frames to encode as altef/golden frames? [17:21:29 CEST] <Thomas_J> WOW! I just discovered gnutls-cli [17:29:26 CEST] <Thomas_J> Anyone familiar with gnutls? Are the same options such as --tofu be used on the ffmpeg command line the same as they are used in gnutls-cli? [17:45:34 CEST] <sine0> hey folks. I am trying to use ffmpeg to squash down a raw avi I got from after effects into an smaller mp4 with no audio [17:46:02 CEST] <sine0> ffmpeg version N-93897-g8f6e651833 [17:46:31 CEST] <sine0> anyway I keep getting these stack dump type outputs [17:46:42 CEST] <sine0> and the resulting file is grey and fux0red [17:47:03 CEST] <sine0> [libx264 @ 000001677a5ec440] frame I:1 Avg QP:19.11 size: 44541 [17:47:03 CEST] <sine0> [libx264 @ 000001677a5ec440] frame P:63 Avg QP:19.78 size: 8567 [17:48:34 CEST] <DHE> that's just detailed encoding information. apparently your video is like 2 seconds long? [17:49:32 CEST] <sine0> no there was more i didnt paste it though.. [17:50:12 CEST] <sine0> im just playing witht he settings I guess the question is, does a raw avi file have all the information needed to convert into another type in ffmpeg [17:50:53 CEST] <DHE> typically. you're seeing what ffmpeg is seeing. you can try ffplay to play the original video directly - if there are inconsistencies there then ffmpeg is having problems reading the source [17:52:18 CEST] <sine0> hmm it plays, smooth and sweet [17:52:57 CEST] <sine0> Stream #0:0: Video: rawvideo, bgra, 1280x720, 740240 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc [17:53:20 CEST] <sine0> ffmpeg -i comp.avi -c:v libx264 -preset fast -f mp4 woot.mp4 [17:53:28 CEST] <sine0> that should work for it amirite [17:53:55 CEST] <sine0> it might be my build I was having problems before, its a windows nightly build.. [17:54:52 CEST] <Thomas_J> gnutls has command line options. How would I pass them to gnutls from within the ffmpeg command line through rtmps://? [17:55:13 CEST] <sine0> im just grabbing 4.1.3 stable [18:02:11 CEST] <DHE> sine0: depending on the player you may have an colourspace issue. try adding "-pix_fmt yuv420p" just before the output filename [18:03:28 CEST] <sine0> I rerendered it from AAE and used a codec [18:03:57 CEST] <sine0> DV PAL [18:06:25 CEST] <cehoyos> There is nothing "unstable" about current FFmpeg and nothing "stable" about an FFmpeg release, releases are just old and unsupported [18:08:39 CEST] <pink_mist> cehoyos: I'd beg to differ - at least from the point of view of writing software that is linking to ffmpeg ... [18:08:51 CEST] <pink_mist> not from a user standpoint though [18:12:44 CEST] <sine0> cehoyos: so nightly builds are always stable ? [18:13:45 CEST] <cehoyos> pink_mist: If you are a distributor, you have to use the buggy, old releases. If you are a user, you don't have to. [18:14:14 CEST] <pink_mist> I'm a distributor [18:14:14 CEST] <cehoyos> No, not "always". But they contain less bugs than any release, and except for special circumstances, it makes no sense to even look at them [18:14:24 CEST] <cehoyos> Is sine0 a distributor? [18:16:10 CEST] <sine0> he is not [18:40:56 CEST] <Thomas_J> How can I pass the option --insecure to gnutls from within the ffmpeg command line? [18:50:28 CEST] <JEEB> Thomas_J: if you mean the certificate verification, then the gnutls TLS protocol module has a "verify" option that can be disabled. the problem is that you're then utilizing another protocol on top of that (rtmps, for example) which then has to also have that option and then pass that onto the TLS implementation [18:53:01 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/rtmpproto.c;h=b7… [18:53:04 CEST] <JEEB> doesn't seem so [18:53:20 CEST] <JEEB> those are the options you can give the RTMP protocol [18:55:13 CEST] <JEEB> if you are on an x86 system then patching that yourself for testing to make sure it's what it means and what you need shouldn't take too long [18:56:06 CEST] <JEEB> and yes I just checked gnutls-cli's --insecure manpage [18:56:21 CEST] <JEEB> it is the certificate validation, which is what the "verify" option in TLS in FFmpeg does [19:07:12 CEST] <JEEB> hmm [19:07:18 CEST] <JEEB> why doesn't https have to do it... [19:07:27 CEST] Action: JEEB goes read how API clients disable certificate checks [19:08:36 CEST] <JEEB> Thomas_J: huh, I have no means of testing this but try setting -tls_verify 1 [19:09:02 CEST] <JEEB> if you need it for input, put it before input. if you need it for output, put it after input and before output [19:12:34 CEST] <JEEB> right. it does pass opts as-is to the lower protocol [19:12:42 CEST] <JEEB> in both HTTP(S) and RTMP [19:15:09 CEST] <Thomas_J> JEEB> the fact that gnutls id hiding behind rtmps is the reason I asked. I discovered gnutls-cli and looking at connecting to Facebook. The Facebook domain has certs but when I probe the full URL of the facebook connection, it doesn't authenticate. [19:16:10 CEST] <Thomas_J> What I am looking for is to be able to try some of the gnutls options from within my ffmpeg string. [19:16:14 CEST] <JEEB> see what I have written, last 7 or so lines should get you the gist :P [19:16:39 CEST] <Thomas_J> Thanks. [19:17:51 CEST] <Thomas_J> "-tls_verify 1" Where will I place this? befor -f flv? [19:18:13 CEST] <JEEB> I commented on the positioning, what matters is before/after input :P [19:18:27 CEST] <JEEB> since all options will be kept pushed to all the modules utilized specifically by ffmpeg.c [19:18:34 CEST] <JEEB> until one of them accepts it [19:19:26 CEST] <JEEB> Thomas_J: also for insecure you probably want 0 there [19:19:27 CEST] <JEEB> not 1 [19:19:28 CEST] <JEEB> :P [19:19:39 CEST] <JEEB> if your logs show that the TLS certificate check is what is failing [19:21:52 CEST] <Thomas_J> Thanks, I'll try it now. Is there documentation on the gnutls options? [19:22:15 CEST] <JEEB> there's a common list of options for the TLS stuff [19:22:24 CEST] <JEEB> I have linekd it in the chat if you scroll up a bit [19:22:28 CEST] <JEEB> it's the git link [19:23:00 CEST] <JEEB> also, if your log level is debug or more (-v debug or more) it should show stuff like "Unable to verify peer certificate" [19:23:04 CEST] <JEEB> if you think that is your issue [19:23:23 CEST] <JEEB> I can link you all the logging the gnutls module does if it fails to verify [19:23:57 CEST] <JEEB> starting from this line there's the av_log lines http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/tls_gnutls.c;h=f… [19:24:01 CEST] <Thomas_J> Thanks. Forgive my rudamentry questions but I can't break the mindset of the order of things is command followed by options and flags. [19:24:18 CEST] <JEEB> and those are actually on the error log level [19:24:26 CEST] <JEEB> so you should have seen those messages if the certificate check was your issue [19:24:31 CEST] <JEEB> even without a high log level [19:24:36 CEST] <JEEB> (since they are errors, d'uh) [19:24:56 CEST] <JEEB> if you do not see them, then that is not your issue [19:25:36 CEST] <JEEB> if you have a log available from f.ex. -v verbose level or higher, people here can help check it if paired with your command line :P (you can clear stuff like RTMP credentials etc from it) [19:25:37 CEST] <Thomas_J> Ran that. To verbose. Yes but now that I now it's a cert problem, I have to go farther. That's where I am delighted to find gnutls-cli. [19:25:55 CEST] <JEEB> Thomas_J: do you actually *know* that is the case? [19:26:01 CEST] <JEEB> do you see those errors I just linked [19:26:03 CEST] <JEEB> in your output [19:26:20 CEST] <JEEB> they should have been always pushed out unless you specifically make ffmpeg.c silent so that it doesn't even log errors [19:26:30 CEST] <JEEB> stuff like "Unable to verify peer certificate [19:27:52 CEST] <Thomas_J> No but at least gnutls gives me a way to further probe down into my suspicions. [19:28:10 CEST] <JEEB> if you do not see that error then stop doing assumptions, PLEASE [19:28:26 CEST] <JEEB> FFmpeg does log TLS verification issues [19:28:29 CEST] <JEEB> as *errors* [19:28:40 CEST] <JEEB> if you do not see those, it either doesn't get that far, or something else [19:29:02 CEST] <Thomas_J> I have seen the error. That is why I think that this rabbit is worth chasing. [19:29:34 CEST] <JEEB> Thomas_J: ok, so you have seen TLS verification errors from *FFmpeg* ? [19:29:46 CEST] <JEEB> please verify this so you can be helped the best way possible [19:31:02 CEST] <JEEB> also I just verified with `ffmpeg -h full |grep "tls_verify"` that the default is 0 [19:31:04 CEST] <Thomas_J> Absolutely. The last time I ran a -v debug, plain as day it said TLS: bla-bla-bla. [19:31:05 CEST] <JEEB> for tls_verify [19:31:41 CEST] <JEEB> yes, it will say TLS something or another at that level of verbosity [19:31:45 CEST] <JEEB> but that is not necessarily an error [19:32:23 CEST] <JEEB> I just do not want you to do wild goose chaces any more than necessary [19:32:58 CEST] <JEEB> you can use -v verbose as your standard and provide a log of a failed attempt [19:33:33 CEST] <Thomas_J> I'm going to get back to digging through the Docs now, In the immortal words of A.S., I'll be back. Or did Mcarther say that? [19:34:11 CEST] <Thomas_J> He said I shall return, That's it. [19:40:19 CEST] <another> Just for the record: How to debug: 1) Get logs. 2) Read the error messages. Don't just skim them, read them carefully. Start at the top; everything further down could be subsequent errors. [19:44:52 CEST] <JEEB> and 3) if you cannot see any clear indications of anything, post the log on a pastebin site and link it here [19:46:17 CEST] <another> i was goinng for a more general approach [21:28:11 CEST] <Thomas_J> What does "Unknown dref type 0x206c7275 size 12" mean? [21:40:56 CEST] <JEEB> Thomas_J: a mp4/mov reference type [21:41:09 CEST] <JEEB> I don't think that is a fatal message sine it's on debug level [21:41:26 CEST] <JEEB> it just mentions that "btw the data also contained this, but I didn't know what to do with it" [21:45:09 CEST] <JEEB> seems to be " lru" which the other way round is "url " [21:45:10 CEST] <Thomas_J> I just triesd another live stream. The console out is this; [21:45:18 CEST] <Thomas_J> [tcp @ 0x3599b60] Successfully connected to 157.240.2.3 port 443 [21:45:18 CEST] <Thomas_J> [rtmps @ 0x3599830] Cannot open connection tls://live-api-s.facebook.com:443 [21:45:18 CEST] <Thomas_J> rtmps://live-api-s.facebook.com:443/rtmp/2373322142735510?s_bl=1&s_ps=1&s_sml=0&s_sw=0&s_vt=api-s&a=AbxqwyoT1iqQLCcV: Resource temporarily unavailable [21:45:18 CEST] <Thomas_J> [AVIOContext @ 0x3599c70] Statistics: 200636 bytes read, 2 seeks [21:46:14 CEST] <JEEB> port 443 sounds like it's not RTMPS but rather RTMP over HTTPS or something? [21:46:21 CEST] <JEEB> not that I know what facebook does [21:46:23 CEST] <Thomas_J> facebook is waiting for my stream. [21:46:41 CEST] <JEEB> ok, sorry [21:46:46 CEST] <JEEB> rtmps default port is indeed 443 [21:47:05 CEST] <JEEB> (I just saw RTMPS_DEFAULT_PORT being defined as 443) [21:47:21 CEST] <Thomas_J> Port 443 is imap tls port. I have no idea why facebook uses that . [21:47:54 CEST] <JEEB> it's just the HTTPS port :) [21:48:40 CEST] <JEEB> anyways, with that you've posted at least some logs :P [21:48:46 CEST] <Thomas_J> Facebook dropped the use of rtmp on May 1st. [21:48:52 CEST] <JEEB> I *know* [21:49:13 CEST] <JEEB> mostly because I happen to share a chat room with one of the Facebook streaming people [21:49:30 CEST] <JEEB> (note: that doesn't mean I know /anything/ about Facebook RTMP) [21:49:31 CEST] <Thomas_J> The rest is just spam going to the console. [21:49:42 CEST] <JEEB> you should be OK with just -v verbose in general [21:50:15 CEST] <JEEB> also next time for multiple lines utilize a pastebin kind of site. any works that is not dumb and can be linked to [21:51:08 CEST] <JEEB> anyways, that shows that opening the underlying protocol failed [21:51:14 CEST] <Thomas_J> Could you do me a favor? could you ask your friend if he is using ffmpeg to stream to Facebook now and if so HOW? [21:51:26 CEST] <JEEB> that person is not my friend [21:52:05 CEST] <Thomas_J> I did not feel comfortable posting my key to a pastebin. [21:52:14 CEST] <JEEB> yes, you can hide stuff like that [21:52:29 CEST] <JEEB> the main part is to just get the general command line and terminal output [21:53:36 CEST] <Thomas_J> At this point, I feal the inclusion could be pertinant to troubleshooting why a tls handshake cannot be made. [21:54:25 CEST] <JEEB> hmm [21:55:03 CEST] <Thomas_J> I am using gnutls as a client. Could it still be expecting a secret key from me? [21:55:31 CEST] <JEEB> is the gnutls client doing HTTPS or just TLS against the server? [21:55:49 CEST] <JEEB> also if you have on a x86_64 machine built FFmpeg yourself, there is a function that you could attempt to make more verbose [21:55:56 CEST] <JEEB> print_tls_error in libavformat/tls_gnutls.c [21:56:06 CEST] <JEEB> it right now only prints out stuff under specific circuimstances [21:56:19 CEST] <JEEB> and unless you filtered something out there were no internal messages from the TLS implementation coming out [21:56:25 CEST] <Thomas_J> Only being used with ffmpeg. [21:56:39 CEST] <JEEB> you have lost me with that response [21:59:05 CEST] <Thomas_J> As far as I know, I am only using gnutls from within ffmpeg for streaming to Facebook. [21:59:45 CEST] <JEEB> ok, and here I thought you had probed FB's end point with the gnutls command line app and were referring to that :P [21:59:50 CEST] <Thomas_J> I believe that it is a module that I compiled. [21:59:52 CEST] <JEEB> sorry, I expected too much out of this [22:01:31 CEST] <Thomas_J> I have probed Facebook with gnotls-cli which I installed separately using apt install. [22:03:29 CEST] <MoziM> hello [22:06:41 CEST] <Thomas_J> Hellloooooo [22:07:27 CEST] <JEEB> Thomas_J: anyways if you have built FFmpeg against gnutls and yourself, then http://up-cat.net/p/a9492457 [22:07:44 CEST] <JEEB> should make it speak a bit more if it fails in a place where print_tls_error gets called :P [22:07:58 CEST] <JEEB> since the log you posted did not contain any gnutls error logging. [22:08:33 CEST] <Thomas_J> Actually, I am now using the pre-built bin that you suggested 2 days ago with gnutls enabled. [22:08:40 CEST] <JEEB> ok, too bad then :P [22:08:58 CEST] <JEEB> it was good for basic testing but you are not suddenly going to get more logging out of it [22:09:22 CEST] <JEEB> maybe try running it under strace? have you been able to connect and handhshake with the gnutls command line application against FB's server? [22:10:15 CEST] <Thomas_J> I haven't tried gnutls from the command line. [22:10:36 CEST] <JEEB> but you just noted > I have probed Facebook with gnutls-cli [22:11:58 CEST] <JEEB> I think, unfortunately, that I'm giving up on you for the day :P it's eleven in the night, and I want to test some things. [22:13:34 CEST] <Thomas_J> The apt installed gnutls-cli is different than the compiled version of gnutls that ffmpeg is linking to.(I think) I know it links to it because the final error is coming from TLS. [22:14:19 CEST] <Thomas_J> When I try gnutls from the command line, it is not in bashes path. [22:14:19 CEST] <JEEB> that message you posted just notes that the connection in general failed [22:14:43 CEST] <JEEB> the connection did happen to be the TLS connection utilized by RTMPS, yes [22:15:08 CEST] <JEEB> but it gives literally zero hints about what failed :P [22:15:36 CEST] <Thomas_J> That time it just failed to connect but when facebook is not set waiting, I get an error message from TLS: [22:16:31 CEST] <JEEB> also [22:16:39 CEST] <JEEB> that resource temporarily unavailable [22:16:44 CEST] <JEEB> is EAGAIN [22:16:53 CEST] <JEEB> aka "please try again". does it actually fail after that? [22:19:21 CEST] <JEEB> if it does it might not be handling EAGAIN during open [22:21:55 CEST] <JEEB> it would be really nice if you can provide the full -v verbose or -v debug log with the credentials hidden in a pastebin or whatever when you have a proper FB publishing point available and you're trying to push to it [22:22:18 CEST] <JEEB> I just want to see the whole shebang because at this point I don't know how I can interpret some things you say [22:26:49 CEST] <Thomas_J> Okay, now I am lost. Trying so many different variances of the command line, I'm at a loss as to how to duplicate the command that made TLS show it's face on the error out. [22:27:50 CEST] <Thomas_J> But I have seen it on occasion so I know it is linked with ffmpeg. [22:30:25 CEST] <Thomas_J> If I leave off the Facebook key at the end of the URI then ffmpeg just sits there waiting for more input. With the complete URL, then ffmpeg completes and ends with the 10 mile long spam to the console and the final ending outputs. [22:32:28 CEST] <Thomas_J> I still think that it is something that I am missing for the setup of gnutls that keeps it from completing a handshake with FB.. [22:38:00 CEST] <Thomas_J> https://pastebin.com/rCPFwGwU/?e=1 [22:42:14 CEST] <Thomas_J> Sorry, that pastebin url is NG. Use: https://pastebin.com/rCPFwGwU [22:44:47 CEST] <Thomas_J> This is the commant string that made TLD report; https://pastebin.com/hDxZPTmP [22:45:54 CEST] <Thomas_J> That's the command string that made TLS report. [22:46:20 CEST] <JEEB> > 4.1.3 [22:46:26 CEST] <JEEB> can you try the master build [22:46:32 CEST] <Thomas_J> My mind says one thing while my flying fingers go somewhere else. [22:46:32 CEST] <JEEB> should be available from the same place [22:46:46 CEST] <JEEB> I think I specifically mentioned using master [22:46:54 CEST] <JEEB> back when linking the build [22:47:38 CEST] <JEEB> because there was a fix that I pushed into master but nobody told which releases they wanted the fix into :P [22:47:44 CEST] <Thomas_J> If that's a bin it has to run in an ARM processor. [22:48:00 CEST] <JEEB> https://www.johnvansickle.com/ffmpeg/ [22:48:06 CEST] <JEEB> like, literally the goddamn same site [22:48:10 CEST] <JEEB> just the left one instead of the right one [22:48:19 CEST] <JEEB> not release but git master :P [22:49:04 CEST] <Thomas_J> 4.1.4 is now current. [22:50:01 CEST] <JEEB> take the master [22:50:04 CEST] <JEEB> not 4.1.4 [22:50:06 CEST] <JEEB> not release [22:50:11 CEST] <JEEB> just take the git master [22:53:26 CEST] <Thomas_J> There is nothing I can see on this page that says master. They are all bin builds for different environments. [22:54:49 CEST] <JEEB> the "git" one is git master [22:54:52 CEST] <JEEB> from that date [22:55:08 CEST] <JEEB> yes I dislike the fact that the page actually doesn't say "git master" [22:55:25 CEST] <JEEB> although the description on that same page mentions it [22:55:26 CEST] <JEEB> > Note: it's highly recommended to use git master builds, because bug fixes and other improvements are added daily. [22:55:35 CEST] <Thomas_J> You suggested I try the armhf build. That's what I am working with now. [22:55:46 CEST] <JEEB> you picked the right one [22:55:49 CEST] <JEEB> see the left side [22:55:52 CEST] <JEEB> for christ's sake [22:55:58 CEST] <JEEB> it has armhf for *both* [22:59:02 CEST] <Thomas_J> OHHH... I didn't relate when it said git master builds are preferred but didn't realize it meant the static builds below. I thought it was advising to get the source from Github. [22:59:38 CEST] <Thomas_J> My bad. [23:05:47 CEST] <Thomas_J> Well! a whole new bunch of error messages. Looks promisig. I'll Pastebin [23:06:27 CEST] <JEEB> yes because now that your log contained the actual version - it was a version without the fix that I applied for gnutls connectivity :P [23:06:49 CEST] <JEEB> I was working under the assumption that since I said "git master" you would have been using the git build [23:06:59 CEST] <JEEB> and thus I was working under the assumption that whatever failed it was not that [23:09:02 CEST] <Thomas_J> https://pastebin.com/hjJwrgVh [23:10:07 CEST] <Thomas_J> I didn't realize that they were 2 columns one for git build and the other side for a NOT get build. [23:10:36 CEST] <JEEB> congrats, you have attained an actual RTMP connection but facebook is now telling you that you are lacking an identifier [23:11:42 CEST] <Thomas_J> SEE! I told you that it looks promising. :) [23:11:56 CEST] <JEEB> and that whole message after "Server error:" comes from FB [23:12:05 CEST] <JEEB> so it's not FFmpeg message but 100% FB [23:12:31 CEST] <Thomas_J> GREAT.I think I can work with that. [23:13:15 CEST] <JEEB> I will attempt to ask the person doing the releases which branches are supposed to still be supported [23:13:26 CEST] <JEEB> because I kind of want to apply that gnutls fix elsewhere as well :P [23:13:34 CEST] <Thomas_J> Why is there non-git builds on that page that don't work wright? [23:14:06 CEST] <JEEB> no, I don't really care about those builds. I just want to know which branches are still within some sort of support and thus I'll stick the fix there :P [23:14:23 CEST] <JEEB> the people creating binaries will eventually make binaries out of newer releases as well [23:14:26 CEST] <JEEB> :P [23:15:48 CEST] <Thomas_J> The problem is, that there are some of us that are old and our eyes aren't what they should be and we don't know the difference anyway and get trapped with builds that should have been taken down. [23:16:26 CEST] <JEEB> well the thing is, as I noted nobody replied to my requests on info regarding which branches (releases) are still updated :P [23:16:33 CEST] <JEEB> -> the fix is only in master right now [23:16:37 CEST] <JEEB> and in the upcoming 4.2 release [23:16:49 CEST] <JEEB> (since new releases get branched off of master) [23:21:19 CEST] <Thomas_J> I see. But, John VanSickle really should take those bad builds down. [23:21:29 CEST] <JEEB> they're not bad [23:21:38 CEST] <Thomas_J> they are a real trap. [23:21:39 CEST] <JEEB> they're just what's within that release at this moment [23:22:12 CEST] <JEEB> as far as I know pretty much the only TLS server which hit that gnutls API usage issue was indeed Facebook [23:22:36 CEST] <JEEB> but anyways, yes. I will attempt to figure out which branches to back-port the fix to :P [23:22:44 CEST] <Thomas_J> But he already put up the newest Git builds and then updated them to v4.1.4. [23:22:59 CEST] <JEEB> they are two separate things [23:23:05 CEST] <kepstin> the 'git master' builds are code that isn't yet available in a release [23:23:09 CEST] <kepstin> and 4.1 is a different branch [23:23:14 CEST] <JEEB> he has one set of master builds, and one set of the latest release branch :P [23:23:16 CEST] <Yuyu0> there is even a recommendation on the page itself to use the git master builds [23:23:38 CEST] <JEEB> anyways, it's a bug - it's fixed - nobody told me where to backport it to :P [23:24:00 CEST] <JEEB> I could have gone for 4.1 only but I'd rather figure out all "currently supported" things [23:24:09 CEST] <JEEB> whatever that means [23:24:18 CEST] <Thomas_J> I see. Then he is only updating the releases as they come through without knowing of the trmp problem. [23:24:24 CEST] <kepstin> I'd assume "everything that hasn't been moved to old releases on https://www.ffmpeg.org/download.html" is probably a good start [23:25:40 CEST] <Thomas_J> Well, I am really glad that we (you) found the problem that I have been butting my head against. [23:40:43 CEST] <Thomas_J> As I type, I now have a live stream running on my Facegbook wall! Thank you, Thank you, Thank you, all. [23:42:03 CEST] <Thomas_J> Almost 2 months of effort and perseverance beyond human trial. [00:00:00 CEST] --- Wed Jul 10 2019

1 0

ffmpeg-devel.log.20190708
by burek 09 Jul '19

09 Jul '19

[00:07:34 CEST] <mkver> Btw: I once reported to Moritz Bunkus (MKVToolNix author) that seeking to some keyframes in some of the files remuxed by mkvmerge fails (my sample was one of these Blurays h264_redundant_pps is about). Now mkvmerge inserts all currently visible SPS+PPS when it encounters changing SPS/PPS in the annex-b input (mp4/mkv input is sent through untouched). But the output has the SPS/PPS after the SEIs. [00:11:54 CEST] <cone-677> ffmpeg 03Andreas Rheinhardt 07master:d78553cc4c79: h264_redundant_pps: Avoid allocations and copies of packet structures [00:11:55 CEST] <cone-677> ffmpeg 03Andreas Rheinhardt 07master:9362f1a98268: h264_redundant_pps: Fix looping over an access unit's units [00:11:56 CEST] <cone-677> ffmpeg 03Andreas Rheinhardt 07master:ddd53ef66d6a: h265_metadata: Avoid allocations and copies of packet structures [00:11:57 CEST] <cone-677> ffmpeg 03Andreas Rheinhardt 07master:bc8b623b83d7: h265_metadata: Correct error check [00:11:58 CEST] <cone-677> ffmpeg 03Andreas Rheinhardt 07master:dd5ce54d2a44: mpeg2_metadata: Avoid allocations and copies of packet structures [00:11:59 CEST] <cone-677> ffmpeg 03Andreas Rheinhardt 07master:42114094da35: mpeg2_metadata: Localize inserting of sequence display extensions [00:12:00 CEST] <cone-677> ffmpeg 03Andreas Rheinhardt 07master:98b122cdb9ef: vp9_metadata: Avoid allocations and copies of packet structures [00:14:23 CEST] <jkqxz> mkver: I'm not sure I quite follow what you mean there. It keeps track of the valid SPS/PPS through the stream, and if it finds an access unit containing any SPS or PPS then it inserts all of the others? [00:15:08 CEST] <mkver> No, only if it finds changing SPS/PPS (meaning a xPS with an id it has already encountered, but with changed content). [00:15:10 CEST] <jkqxz> (13/14 got minor fixup to apply cleanly, you'll need to rebase when that collides in the other direction.) [00:17:05 CEST] <jkqxz> So for the bluray streams, it would add the SPS next to the changing PPSs? [00:19:36 CEST] <jkqxz> For 20, was there a good reason not to use 0 rather than -1 as the default value? I vaguely remember some comment on that before. [00:20:34 CEST] <mkver> It would be SEI-SPS-PPS-slices [00:21:27 CEST] <mkver> Yes. 0 is only forbidden for MPEG-2 and the function to update the AVCodecParameters treats 0 therefore as a valid value. [00:22:06 CEST] <jkqxz> For 21, I didn't find where that came from. I guess it's fine, and if someone does find it and complains about getting 9001 warnings we probably tell them to ignore warnings from stupid compilers. [00:27:44 CEST] <mkver> Ok. Someone using such a compiler should actually be used to such warnings anyway. [00:30:02 CEST] <jkqxz> I can't see anything which disallows SEI-SPS-PPS, but that feels weird. [00:30:43 CEST] <jkqxz> On 20, I mean for the arguments to the BSF. [00:32:11 CEST] <mkver> Yeah. If we use 0 as default "don't change anything" value, then one has to translate this to the form the function used to update the AVCodecParameters expects. [00:32:21 CEST] <mkver> Doable, of course. [00:32:45 CEST] <mkver> Btw: What's your opinion of giving the user a choice in whether the AVCodecParameters are updated? [01:06:42 CEST] <jkqxz> Perhaps the user-side is more interesting for the zero default. mpeg2_metadata=colour_primaries=0 erroring out telling you you're being stupid is probably better than it silently doing nothing. [01:18:41 CEST] <mkver> Sent the delete unit/SEI message patches. [01:19:48 CEST] <jkqxz> On AVCodecParmaters, I'm ambivalent. jamrial has a sensible argument, but we never did update before so it is a change. [01:20:46 CEST] <jamrial> jkqxz: we could bump minor for it, if you want [01:20:54 CEST] <jkqxz> When it was originally written, the reason for not updating it was a combination of laziness and a general feeling that you don't really want to trust those values anyway. [01:21:16 CEST] <jkqxz> (The second part of that allowing the first to win.) [01:22:24 CEST] <jamrial> With h264 or h265 yeah, probably better to ignore container info, but not really for vp9 [01:24:01 CEST] <jkqxz> I guess that means that once you're updating it you might as well always do it. No reason to keep the old values when the new ones should be not-worse (even if you don't really trust them). [01:25:30 CEST] <jkqxz> ... which means I probably agree with jamrial. [01:25:38 CEST] <jkqxz> mkver: Do you have any use-case in mind for not updating? [01:26:13 CEST] <jkqxz> (Beyond a pure "get the old behaviour back".) [01:27:35 CEST] <mkver> Maybe if the codec allows to only encode a subset of the possible values for a parameter, then one could set the bitstream to the one most closely matching the desired parameter and put the true value in the container in order to increase the chance that players will do the right thing. [01:29:23 CEST] <jkqxz> Hmm. Which value should go on the container for H.26[45] HLG? [01:29:51 CEST] <jkqxz> (Trying to think of an example of a case like that.) [01:31:10 CEST] <JEEB> I think youtube had some HLG VP9 clips [01:31:30 CEST] <mkver> H.264 don't allow to set the chroma sample location to "unknown". [01:31:46 CEST] <JEEB> the default is the BT.709 one I think? [01:31:49 CEST] <JEEB> top left [01:31:58 CEST] <mkver> Yes. [01:32:26 CEST] <JEEB> ok, the webm spec actually mentions the TransferCharacteristics box https://www.webmproject.org/docs/container/ [01:32:29 CEST] <mkver> No, middle left. [01:32:30 CEST] <JEEB> which contains HLG [01:32:34 CEST] <JEEB> mkver: ah, sorry :) [01:34:19 CEST] <JEEB> and as I wondered the vp9 mp4 spec also defines some boxes https://www.webmproject.org/vp9/mp4/ [01:34:47 CEST] <jkqxz> JEEB: I was thinking of H.26[45] specifcally because of the use of the 709 value in the SPS and then putting the real value in the alternative transfer characteristics SEI message. [01:34:52 CEST] <JEEB> ah [01:34:55 CEST] <JEEB> ok, sorry [01:35:16 CEST] <jamrial> jkqxz: for hlg, h264 would use the alternative transfer function sei [01:35:18 CEST] <JEEB> those both were not in the container level so that's why I seem to have broken down without enough concept [01:35:47 CEST] <JEEB> also my English is seemingly breaking as well, sorry. I think I'll hit the sack at this point :D [01:35:48 CEST] <jamrial> with the transfer function value in the VUI and container being a "fallback" one [01:36:36 CEST] <jkqxz> So the container would get the 709 value? Is this hacked somewhere, or does that mean it's an example of a case where we should be putting the wrong value in AVCodecParameters... [01:38:23 CEST] <jamrial> i can't say. they only hlg sample i have is in mpegts, which doesn't seem to have container color info [01:39:14 CEST] <jamrial> but since the arib-std-b67 is purposely written in a SEI for backwards compat reasons, i'm going to assume the container value, if any, should match the VUI "fallback" one [01:41:12 CEST] <jamrial> which in this sample is bt2020_10 [02:53:22 CEST] <mkver> I presume that no decision on this will be forthcoming today? [03:02:19 CEST] <mkver> Good night. [10:17:31 CEST] <durandal_1707> kierank: the cfhd sample you gave me is strange - every 2nd packet is PFRAME but only size of 24, and the another sample is bayer actually [10:17:48 CEST] <kierank> durandal_1707: it's a skip frame then [10:18:11 CEST] <kierank> the mov files are bayer [10:18:14 CEST] <kierank> from reto [10:18:37 CEST] <durandal_1707> kierank: the spider too [10:18:44 CEST] <kierank> durandal_1707: yes [10:18:47 CEST] <kierank> you wanted bayer samples [10:19:09 CEST] <durandal_1707> no, i wanted world class samples [10:19:44 CEST] <kierank> https://github.com/gopro/cineform-sdk/tree/master/Example/videos [10:39:36 CEST] <durandal_1707> kierank: not P-frames [11:40:49 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:e96b7a8ba62c: avcodec/dxv: Initialize tex_funct to NULL [11:40:49 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:a6474b899c11: avcodec/alac: Check lpc_quant [11:40:49 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:79204a1fc8f1: avcodec/vc1_block: Check for vlc error in vc1_decode_ac_coeff() [11:40:49 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:37708cbae8d6: avcodec/flicvideo: Fix off by 1 error in flic_decode_frame_24BPP() [11:40:49 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:cf2bd3ce79b1: avcodec/ffwavesynth: Fix backward lcg_seek() [11:40:49 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:8c022099351c: avcodec/ffwavesynth: Simplify lcg_seek(), avoid negative case [11:40:49 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:e9dd3c712609: avcodec/ffwavesynth: use uint32_t to compute difference, it is enough [11:40:50 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:f76d7352e055: avcodec/iff: Check ham vs bpp [11:40:51 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:7b114d76878f: avcodec/svq3: Use ff_set_dimension() [11:40:52 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:b5f2cfd2ad2b: avcodec/simple_idct_template: Fix integer overflow in idctSparseCol() [11:40:53 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:85cbd042ff80: avcodec/simple_idct_template: Fix integer overflow in idctSparseColAdd() [11:40:54 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:ae021c1239ec: avcodec/qdm2: Do not read out of array in fix_coding_method_array() [11:40:55 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:694be24bd6c4: avcodec/qdm2: error out of qdm2_fft_decode_tones() before entering endless loop [11:40:56 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:7b2ebf89a411: avcodec/qdm2: Check checksum_size for 0 [11:40:57 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:2bbea155bf7c: avcodec/4xm: Fix signed integer overflows in idct() [11:40:58 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:e69106e70c89: avformat/vividas: Check for input length in get_v() [11:40:59 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:936ca7f1012e: avcodec/sanm: Optimize fill_frame() with av_memcpy_backptr() [11:41:00 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:17209e48e28d: avcodec/tta: Limit decoder to 16 channels [11:41:01 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:14fcf4295860: avcodec/rv10: Fix integer overflow in aspect ratio compare [11:41:02 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:a6229fcd405d: avcodec/hq_hqa: Use ff_set_dimensions() [11:41:03 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:f57e97dfd953: avformat/utils: Check timebase before use in estimate_timings() [11:41:04 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:1bb3b3f11c69: avcodec/golomb: Correct the doxy about get_ue_golomb() and errors [11:41:05 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07master:019d729039aa: avcodec/ilbcdec: Simplify use of unsigned and fix more undefined overflows [13:10:10 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:3d1903acfee8: avcodec/atrac9dec: Check that the reused block has succeeded initilization [13:10:11 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:7daa138f6819: avcodec/atrac9dec: Check q_unit_cnt in parse_band_ext() [13:10:12 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:5b8bce805c68: avformat/vqf: Check header_size [13:10:13 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:1aa0c2a06f00: avcodec/libvorbisdec: Check extradata size [13:10:14 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:423d0bbc5567: avcodec/qdm2: Move fft_order check up [13:10:15 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:f3bfb0717982: avcodec/m101: Fix off be 2 error [13:10:16 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:b5d6b509b1ce: avcodec/fitsdec: Check data_min/max [13:10:17 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:7d075c5f337f: avformat/aviobuf: Delay buffer downsizing until asserts are met [13:10:18 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:523a47b3f600: avcodec/apedec: Add k < 24 check to the only k++ case which lacks such a check [13:10:19 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:3fa15bb096b1: avcodec/hevc_ps: Fix integer overflow with num_tile_rows and num_tile_columns [13:10:20 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:df61ec263faa: avcodec/hevc_ps: Change num_tile_rows/columns checks to sps->ctb_height/weight [13:10:21 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:105621754052: avcodec/alsdec: Fixes invalid shifts in read_var_block_data() and INTERLEAVE_OUTPUT() [13:10:22 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:dcef55b5ff8e: avcodec/alsdec: Fix undefined behavior in decode_rice() [13:10:23 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:99745dc2f353: avcodec/alsdec: Fix integer overflow with shifting samples [13:10:24 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:75e838a6daa7: avcodec/alsdec: Check opt_order / sb_length in ra_block handling [13:10:25 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:ed8e191bfb1f: avcodec/alsdec: Fixes signed integer overflow in LSB addition [13:10:26 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:fa2dbcfd8f4b: avcodec/alsdec: Fix integer overflow with buffer number [13:10:27 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:c34512371e1d: avcodec/alsdec: Add FF_CODEC_CAP_INIT_CLEANUP [13:10:28 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:c697819aee7f: avcodec/dxv: Initialize tex_funct to NULL [13:10:29 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:ac9d8e7c501c: avcodec/alac: Check lpc_quant [13:10:30 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:4d7ee3b0ff12: avcodec/vc1_block: Check for vlc error in vc1_decode_ac_coeff() [13:10:31 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:10880dd695da: avcodec/flicvideo: Fix off by 1 error in flic_decode_frame_24BPP() [13:10:32 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:24ea2679e2c9: avcodec/ffwavesynth: Fix backward lcg_seek() [13:10:33 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:73885bf3e196: avcodec/ffwavesynth: Simplify lcg_seek(), avoid negative case [13:10:34 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:074f40608e19: avcodec/ffwavesynth: use uint32_t to compute difference, it is enough [13:10:35 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:d534cb834564: avcodec/iff: Check ham vs bpp [13:10:36 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:dd59d92e942f: avcodec/svq3: Use ff_set_dimension() [13:10:37 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:e5c21ed6e35e: avcodec/qdm2: Do not read out of array in fix_coding_method_array() [13:10:38 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:07975e89d326: avcodec/qdm2: error out of qdm2_fft_decode_tones() before entering endless loop [13:10:39 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:2424d0096e30: avcodec/qdm2: Check checksum_size for 0 [13:10:40 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:4db3ec5e7b1a: avcodec/4xm: Fix signed integer overflows in idct() [13:10:41 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:16f8e50f86ce: avcodec/rv10: Fix integer overflow in aspect ratio compare [13:10:42 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:3e3db6919380: avcodec/hq_hqa: Use ff_set_dimensions() [13:10:43 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:a1416c6c8d12: avformat/utils: Check timebase before use in estimate_timings() [13:10:44 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:6ddb253f7967: avcodec/golomb: Correct the doxy about get_ue_golomb() and errors [13:10:45 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:7654e5aa3b6e: avcodec/ilbcdec: Simplify use of unsigned and fix more undefined overflows [13:10:46 CEST] <cone-312> ffmpeg 03Michael Niedermayer 07release/4.1:7d4e9074c6ab: Changelog: update [14:52:26 CEST] <durandal_1707> why this tests fails: http://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-valgrind&time=2… ? [14:53:37 CEST] <jamrial> those have been failing since the host updated gcc and valgrind, so probably false positives [14:57:27 CEST] <ubitux> let me try to upgrade [15:56:08 CEST] <BtbN> hm, VERY tempted to buy a 3900X right now [16:32:26 CEST] <cone-618> ffmpeg 03Paul B Mahol 07master:7b2d39fc2754: avfilter/af_biquads: implement mix option to all filters [16:32:26 CEST] <cone-618> ffmpeg 03Paul B Mahol 07master:034a9d2507e1: avfilter/af_biquads: clip gain picked from command to sane values [16:40:30 CEST] <nevcairiel> I'm still sad that there is still no upgrade for people like me that bought a high-end system years ago, Ryzen is like a side-grade now. I wish it would OC more, then it might be fun. Don't get me wrong, its really nice if you are more generations behind or coming from some mid-range consumer CPU, but if you have a 7900X like myself, which OCs wonderfully as well, I guess i'm stuck at least another year or two, yet the upgrade [16:40:30 CEST] <nevcairiel> itch wants to be scratched =p [16:49:42 CEST] <cone-618> ffmpeg 03Paul B Mahol 07master:2a801e8856da: avfilter/af_aiir: implement mix option [17:22:43 CEST] <J_Darnley> I'd like to thank the person/people responsible for this warning message that gets spammed for every file that includes the header mem.h [17:23:00 CEST] <J_Darnley> ./libavutil/mem.h:342:1: warning: alloc_size attribute ignored on a function returning int [-Wattributes] [17:26:35 CEST] <JEEB> probably can be shut up with something like s/int/size_t/ ? [17:26:51 CEST] <JEEB> or whatever the correct type is for sizes [17:27:18 CEST] <JEEB> (without looking at which function is being spoken of) [17:27:42 CEST] <J_Darnley> "av_alloc_size(2, 3) int av_reallocp_array(void *ptr, size_t nmemb, size_t size);" is the line. [17:28:36 CEST] <J_Darnley> Or maybe this is a new gcc's fault [17:28:52 CEST] <jkqxz> 4361293fcf59edb56879c36edcd25f0a91e0edf8 [17:29:33 CEST] <jkqxz> Presumably that's a branch; it could be backported if the warning is annoying now. [17:29:33 CEST] <J_Darnley> Ah [17:30:04 CEST] <JEEB> yup, the function returns an int so the attribute is incorrect :) [17:30:28 CEST] <J_Darnley> It is a private branch, that I am trying to see if there is a bug in or whether a merge of master has caused it. [17:34:52 CEST] <J_Darnley> Useful to know what I should cherry pick though [17:39:07 CEST] <kierank> J_Darnley: it's a public branch, no? [17:42:12 CEST] <mkver> jkqxz: Did you initially intend to use the golomb.h exponential-golomb functions? cbs_h2645 still includes that header, but doesn't use it. And there is also a configure dependency. [17:44:19 CEST] <J_Darnley> kierank: oh, yes, I guess so [17:44:43 CEST] <J_Darnley> Not one of FFmpeg's though [17:44:51 CEST] <kierank> I do what VLC does and just pick a random commit, apply hacks to fix swscale issues and then release [17:48:00 CEST] <durandal_1707> kierank: what are you talking about? [17:48:23 CEST] <kierank> durandal_1707: internal stuff, doesn't concern you [17:48:42 CEST] <kierank> internal fork of ffmpeg to fix swcale doing stupid operations [17:49:33 CEST] <durandal_1707> kierank: please send patches! [17:49:38 CEST] <kierank> can't [17:49:42 CEST] <kierank> swscale too complex [17:49:51 CEST] <durandal_1707> cehoyos: tell him, please!!!!!!!! [17:50:51 CEST] <kierank> swscale when doing yuv422p10 -> yuv420p10 will do (uint16_t)((uint32_t)(x * 2^n) >> n) [17:50:57 CEST] <kierank> burns like 10% of a cpu core [17:51:31 CEST] <durandal_1707> michaelni: please fix swscale, stop doing boring fuzzing job!!!! [17:56:19 CEST] <jkqxz> mkver: Yeah, it used them for a short time before I realised they were unsafe. Do remove that if you like. [17:59:53 CEST] <cone-618> ffmpeg 03Paul B Mahol 07master:dc481105a1d4: avfilter/vf_tinterlace: re-enable lowpass option [19:25:16 CEST] <cone-618> ffmpeg 03Paul B Mahol 07master:9e78c73d8628: avfilter/vf_readeia608: implement lowpass operation prior to processing lines [19:31:44 CEST] <cone-618> ffmpeg 03Paul B Mahol 07master:43160c7bc476: doc/filters: document new readeia608 option [20:11:45 CEST] <cone-618> ffmpeg 03Michael Niedermayer 07release/4.1:9d06c1f95ebe: Changelog: fix typo [20:18:55 CEST] <cone-618> ffmpeg 03Paul B Mahol 07n4.1.4:HEAD: doc/filters: document new readeia608 option [20:39:10 CEST] <cone-618> ffmpeg 03Thilo Borgmann 07master:48cf95241152: lavd/avfoundation: Remove useless index increment. [20:39:11 CEST] <cone-618> ffmpeg 03Thilo Borgmann 07master:7d4df4b33939: lavd/avfoundation: Change binary Options to boolean type. [20:39:12 CEST] <cone-618> ffmpeg 03Thilo Borgmann 07master:3a5f9ab8146d: lavd/avfoundation: Refine some log messages. [20:39:13 CEST] <cone-618> ffmpeg 03Thilo Borgmann 07master:02f65678ba9b: lavd/avfoundation: Support muxed type of devices including raw muxed data capture. [20:39:14 CEST] <cone-618> ffmpeg 03Thilo Borgmann 07master:5c2e0e417ac8: lavd/avfoundation: Reindent after last commit. [20:39:15 CEST] <cone-618> ffmpeg 03Thilo Borgmann 07master:d16f2fafae10: doc/indevs: Add new option and example to avfoundation. [20:39:16 CEST] <cone-618> ffmpeg 03Thilo Borgmann 07master:70a4f46e48da: lavd/avfoundation: Set correct default value 0 for option capture_raw_data. [22:39:50 CEST] <durandal_1707> no 4.2 still? :( [22:45:04 CEST] <jamrial> durandal_1707: help review matroska patches [00:00:00 CEST] --- Tue Jul 9 2019

1 0

ffmpeg.log.20190708
by burek 09 Jul '19

09 Jul '19

[01:57:40 CEST] <Kozi> hi [01:58:59 CEST] <Kozi> finally... I have a question: can I remove specific subtitles from .mkv files (based on their language) with ffmpeg, and if so, how? [02:01:51 CEST] <nadermx> I'm currently trying to merge a video and audio from YouTube and have it output to stdout via -. The problem is, it seems that it makes the video but the last 10-20 seconds of the video are silent. If I have it output to .mp4 it has the audio till the end. [02:20:51 CEST] <furq> Kozi: -i foo.mkv -c copy -map -0:m:language:eng bar.mkv [02:21:10 CEST] <furq> but that will remove all streams tagged with that language [02:21:40 CEST] <furq> you could also just find which stream number it is and -map -0:n [02:32:52 CEST] <Kozi> Thank you furq. Will try it out later. got to go.. [05:08:42 CEST] <ossifrage> Has anyone tried to build ffmpeg with --enable-lto and gcc 9.1.1? [05:13:47 CEST] <furq> no but i've built with lto before [14:22:46 CEST] <termos> /usr/bin/ld: /usr/local/lib/libavutil.a(hash.o): relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIC [14:23:01 CEST] <termos> anyone have experience with this when compiling against ffmpeg on newer ubuntus? [14:35:29 CEST] <DHE> static libs shouldn't have that problem unless a shared library is being built that needs it [14:35:32 CEST] <DHE> what are you building? [14:40:15 CEST] <termos> hmm i'm building some software we have that's linking against libffmpeg, it's being built all over the place and it's the first time we see this. really weird [14:40:36 CEST] <JEEB> whatever libffmpeg is, have fun with that [14:40:47 CEST] <termos> well, ffmpeg :) [14:42:04 CEST] <durandal_1707> we do not support libffmpeg in any way [14:42:36 CEST] <JEEB> anyways, sounds like you have a custom FFmpeg there, and if it's static make sure that PIC is utilized. I think under various circuimstances it gets enabled by default. in that case it's your own application that needs to be PIC [14:43:09 CEST] <JEEB> checking your own FFmpeg ffbuild/config.log should see if you have enable-pic around or not [14:43:38 CEST] <DHE> probably not. I'm guessing you want to rebuild with --enable-shared --extra-cflags=-fPIC [14:44:01 CEST] <JEEB> there's a standard option for PIC I think [14:44:07 CEST] <JEEB> so you don't need custom cflags for it AFAICS [14:44:42 CEST] <DHE> looking at the configure script I don't see it for gcc [14:46:05 CEST] <JEEB> see enabled pic && enable_weak_pic [14:46:14 CEST] <JEEB> and the enable_weak_pic function [14:46:30 CEST] <JEEB> if you --enable-pic you should get -fPIC to both asflags and cflags :P [14:52:25 CEST] <termos> hmm thanks! i haven't needed any of those flags before [14:52:43 CEST] <JEEB> it depends on what the builds depend on [14:52:58 CEST] <JEEB> it might be FFmpeg, it might your app, it might be a dependency of FFmpeg or your app adding the requirement [14:55:20 CEST] <DHE> I'm thinking if you're building a shared library (hypothetically, libvlc) which depended on ffmpeg, that would require these options [17:01:20 CEST] <Thomas_J> Good Morning. [20:29:24 CEST] <Fenrirthviti> Might be the wrong place to ask, but is anyone familiar with how the licensing for NVENC HEVC works in relation to ffmpeg? Trying to sort out of NVIDIA is sublicensing it as part of their APIs or if there are other concerns on distributing builds with it enabled. [20:33:06 CEST] <Mavrik> Fenrirthviti, IIRC NVENC headers are MIT licensed [20:33:39 CEST] <Fenrirthviti> Sure, but trying to sort out how they handle HEVC licensing [20:33:45 CEST] <Fenrirthviti> not NVENC [20:34:18 CEST] <Mavrik> You mean patents? [20:35:09 CEST] <Fenrirthviti> No, I mean the licensing fees. [20:35:25 CEST] <Fenrirthviti> which I guess is patent licensing? [20:35:30 CEST] <Fenrirthviti> maybe we're talking about the same thing [20:36:27 CEST] <Mavrik> Yeah, I think we are. [20:36:46 CEST] <Mavrik> According to SDK license paying patent royalties is up to you... whatever that means :/ [20:36:57 CEST] <Fenrirthviti> Right, which is the part that's confusing. [20:37:09 CEST] <Fenrirthviti> AMD has a similar disclaimer for their hardware encoders [20:38:09 CEST] <Fenrirthviti> So I'm not sure if we would be required to provide some kind of disclaimer on that as part of the use of the NVENC HEVC encoder, or if we fail to provide that disclaimer we become liable for content created and not paid for [20:39:29 CEST] <Mavrik> Yeah, honestly I've never managed to untangle the HEVC royalties mess properly :/ [20:42:20 CEST] <JEEB> you've got X different places wanting slightly different things, and in the best cases there are multiple places where a certain OEM is licensing their stuff [20:42:39 CEST] <JEEB> I mean, even with H.264 it wasn't technically only MPEG-LA, but the playing field was pretty simple [20:42:49 CEST] <JEEB> (Nokia IIRC kept out of MPEG-LA?) [20:43:05 CEST] <Mavrik> Yeah, I'm assuming that Nvidia does pay the encoder license right? [20:43:14 CEST] <Mavrik> That is, per-encoder HW [20:43:21 CEST] <Mavrik> But not the parts that are per-title [20:43:44 CEST] <JEEB> they probably pay *something*, yes. then again a lot of stuff is supposed to be paid by the entity that gives the result to an end user [20:43:52 CEST] <JEEB> I'm not sure how that even went with MPEG-LA :P [20:44:17 CEST] <Mavrik> Man, some of those royalties aren't even public [20:44:22 CEST] <JEEB> if you f.ex. build a box for someone does it technically require a license to be paid by you because you are the one providing the final solution to the end user [20:44:33 CEST] <JEEB> Mavrik: yea the best license pools don't have a tl;dr [20:44:38 CEST] <JEEB> they make you contact them [20:44:41 CEST] <JEEB> and then $$$ [20:47:06 CEST] <Mavrik> *sigh* So basically you buy encoders, install them and call the racketeers to check how much money they can extract from you. :D [20:47:30 CEST] <JEEB> but yea, if you are the end user and you've been provided a hardware product then if I recall correctly most of the hw licensing doesn't apply, but then the places that have output related licensing come in [20:48:06 CEST] <JEEB> at that point I'm just way too deep for my own good as I'm not a lawyer and such stuff is way over my pay grade :P [20:48:17 CEST] <Mavrik> Mhm, it gets complicated when you do stuff like encode HEVC for profit. E.g. youtubers :) [20:48:31 CEST] <JEEB> yea, I remember some places licensing the content/outputs [20:48:49 CEST] <JEEB> I don't remember which it was that scared the shit out of people by wanting like 5% of income or something [20:49:00 CEST] <Fenrirthviti> aight, fair enough. [20:49:21 CEST] <Fenrirthviti> Glad I'm not the only one who finds this extremely confusing, heh [20:51:11 CEST] <JEEB> thankfully some of the pools mostly focused on licensing hardware solutions for end users, so unless you were the one providing hardware to end users, it "didn't apply" to you [20:51:24 CEST] <JEEB> but then there were the batshit insane ones [20:51:26 CEST] <JEEB> 8) [20:51:41 CEST] <Fenrirthviti> yeah where you had to pay for just being in the same room as an HEVC signal, yours or not. [20:53:36 CEST] <DHE> don't suppose vp9 is an alternative... I assume not if you're going for hardware encoding. [20:53:46 CEST] <Fenrirthviti> It's for NVENC [20:53:49 CEST] <Fenrirthviti> so yes, hardware [20:54:22 CEST] <Fenrirthviti> full context is for OBS, we've been asked a few times to implement native NVENC HEVC since using our ffmpeg output option is a bit of a mess [20:54:46 CEST] <Fenrirthviti> we typically just cite "licensing concerns" as a reason not to do it, but trying to educate myself to have a better conversation around it [20:55:05 CEST] <Fenrirthviti> So was curious how you guys approached it [20:55:16 CEST] <JEEB> FFmpeg generally takes no comment on patent licensing [20:55:22 CEST] <JEEB> and we do not officially distribute binaries [20:55:30 CEST] <Fenrirthviti> Yeah, that's true. [21:15:05 CEST] <Thomas_J> ITrying to get a stream working with Facebook. I just discovered that the quotes in front of "rtmps:// is actually not a typo but things actually start happening. all-be-it not what I need happening, if it is used. [21:17:00 CEST] <Thomas_J> Does anyone have any idea sa to how the Quote should be used to make TLS:// work properly? [21:17:26 CEST] <DHE> that's a commandline thing. if you just write "http://whatever.com/" on a shell, the quotes don't matter. [21:18:04 CEST] <Thomas_J> I talking rtmps, not http. [21:19:00 CEST] <Thomas_J> rtmp just works but rtmps hands off to the tls handler and things here do not work. [21:23:49 CEST] <kepstin> Thomas_J: are you on windows? iirc the windows shell has really weird quoting behaviour - most of the docs you'll find for ffmpeg assume linux shell style quoting [21:23:59 CEST] <Thomas_J> Ubuntu [21:24:49 CEST] <kepstin> one thing to note on linux is that the & character which can appear in urls has special meaning to the shell and must be quoted [21:25:03 CEST] <kepstin> this one hits me all the time when I'm trying to wget stuff :) [21:26:47 CEST] <Thomas_J> The closest I have gotten is that I can get a message back "Resource temporarily unavailable". I understand that special chars usually have to be excapped but how to od that with gnotls handling the command string? [21:26:54 CEST] <xantoz> kepstin: better quoted than sorry [21:27:26 CEST] <furq> kepstin: wouldn't it be cool if some popular service decided to put ! in their urls [21:27:27 CEST] <Thomas_J> Never had problems with wget. [21:27:46 CEST] <furq> perhaps based in new zealand and operated by a fat egomaniac [21:27:51 CEST] <furq> we can only dream though [21:28:26 CEST] <Thomas_J> File names with spaces are allowed but you have to delimit them with quotes when loading. [21:28:43 CEST] <xantoz> furq: more fun if they'd put single or double quotes in there [21:28:56 CEST] <kepstin> Thomas_J: the tls library doesn't see or deal with urls at all, so i don't think that's really your problem [21:28:59 CEST] <furq> well ! gets interpreted as job control stuff in doublequotes [21:29:02 CEST] <furq> so you have to singlequote it [21:29:02 CEST] <xantoz> maybe a combination of $ and single quotes? [21:29:03 CEST] <Thomas_J> Those 2 mean different things. [21:29:05 CEST] <furq> that's great fun [21:29:28 CEST] <xantoz> then you'll have to escape stuff manually no matter what [21:29:29 CEST] <furq> also it's job control stuff so it doesn't go in your history if you forget [21:32:47 CEST] <Thomas_J> The thing is that when interpreting the ffmpeg string, the module that the following part of the string is now being parsed by that module and has it's own set of rules as to how to parse the command line. You just hope that common conventions are being observed. [21:38:57 CEST] <ak22> How do I mix 7 mono inputs (FL, FR, FC, BL, BR, SL, SR) to stereo? [21:39:28 CEST] <Thomas_J> Wow, I am getting to old. That last line made sense to me while I was writing it. [21:41:59 CEST] <durandal_1707> ak22: with pan filter, or if you want binaural with headphone/sofalizer/afir/... filters [21:42:39 CEST] <durandal_1707> using amerge/join with pan, more correctly [21:43:22 CEST] <Thomas_J> Is there anywhere on the Internet where I can find help with writing a ffmpeg command string for rtmps'ing to Facebook? [21:48:54 CEST] <Fenrirthviti> Thomas_J: Getting the output and errors so that people can review the issue fully is probably more helpful [21:49:18 CEST] <Fenrirthviti> There's a good chance that the quotations don't really have anything to do with your issue [21:50:12 CEST] <Fenrirthviti> If you're trying to run a command, paste the output with errors to a gist or similar and link it so people can view it and see what's going on [22:03:03 CEST] <Thomas_J> I have been trying to get this working for over a month without success. The Quotes, I just tried today for the first time even though it doesn't make any sense. When I did, I was surprised that I actually got something besides just staring at a running ffmpeg line without anything happening [22:04:30 CEST] <Thomas_J> I can make things work with rtmp streaming but rtmps will not cooperate. [22:07:18 CEST] <Thomas_J> I have no other way other than streaming my tests directly to Facebook. I have nothing that takes a rtmps input to check my work with. nginx is not equipped for rtmps. [22:18:39 CEST] <Thomas_J> Fenrirthviti> When I run ffmpeg with rtmps:// without a quote, the process just sits there idle until I hit the enter key that ends the exec.When I use a d-quote before the rtmps:// it gives me a prompt">" like it is waiting for more input. When I use d-quote before the rtmps:// and at the end of the uri string, that's when I get the error "Resource temporarily unavailable". [22:19:17 CEST] <Fenrirthviti> I can't really help without seeing the full command and output. [22:19:32 CEST] <Fenrirthviti> Which is why I asked for it [22:19:51 CEST] <Thomas_J> let me pastebin [22:37:30 CEST] <plspgnl> Is anyone know if there is an option to not decode frame if these have error in it with H264 codec. To comparison VP9 codec display by default the last frame without error. [22:38:58 CEST] <plspgnl> This is to not display glitches while decoding [22:41:26 CEST] <Thomas_J> Here are my tests. https://pastebin.com/Re628Wu8 [23:38:18 CEST] <Thomas_J> Has anyone had a chance to look at my pastebin yet? https://pastebin.com/Re628Wu8 [00:00:00 CEST] --- Tue Jul 9 2019

1 0