Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

August 2017

1 participants
62 discussions

ffmpeg-devel.log.20170830
by burek 31 Aug '17

31 Aug '17

[02:16:55 CEST] <cone-376> ffmpeg 03Michael Niedermayer 07master:f762555a9079: avformat/mxfenc: Replace literal numbers by named enum values. [11:27:08 CEST] <cone-221> ffmpeg 03Timo Rothenpieler 07master:1ac03c8dc0a9: configure: add support for libnpp* from cuda sdk 9 [11:27:09 CEST] <cone-221> ffmpeg 03Ricardo Constantino 07master:7fbc0825773e: compat/cuda/ptx2c: strip CR from each line [11:29:23 CEST] <wbs> if anybody cares; I see a lot of discussion around handling and parsing of dash segment file template handling, and potential exploitability around that and so on [11:29:35 CEST] <wbs> ... there's already code that does that, that should be pretty ok, in dashenc.c [11:29:57 CEST] <wbs> so instead of reinventing the wheel, that could be reused/shared, so there's at least a single set of common vulnerabilities, instead of two different sets [11:33:13 CEST] <BtbN> I'm pretty sure dashenc does not parse dash segments. [11:33:24 CEST] <BtbN> it only writes them, which is far more trivial [11:34:09 CEST] <BtbN> dashdec needs a full xml parser though [11:34:24 CEST] <wbs> no, that's not what they are arguing about [11:35:23 CEST] <wbs> within the dash spec, there's a feature that you can have segment names in the form segment-$Bandwidth03d$-$Time$.m4s [11:35:40 CEST] <wbs> so a dash demuxer needs to interpret this and plug in values for bandwidth and time to find the file name to request [11:35:57 CEST] <wbs> now, the dash muxer also has support for this; the user can provide the pattern to use, so the muxer writes filenames in the given pattern [11:36:19 CEST] <BtbN> In that case, the pattern is given on the ffmpeg commandline though. [11:36:32 CEST] <wbs> so? [11:36:42 CEST] <wbs> my point is, there is an exact piece of code that does exactly this [11:36:42 CEST] <BtbN> In the other case, it's given in the file itself. And you don't ever put format strings from input data into the printf family. [11:36:47 CEST] <BtbN> That's a security vulnerability. [11:36:50 CEST] <wbs> exactly [11:37:07 CEST] <BtbN> So there is no issue there in dashenc, as it's not parsing input data. [11:37:16 CEST] <wbs> ... so? [11:37:22 CEST] <wbs> there is code there already, without known vulnerabilities [11:37:23 CEST] <BtbN> ? [11:37:36 CEST] <BtbN> The code in dashenc is vastly different. [11:37:46 CEST] <BtbN> It does a whole diffrent job [11:37:49 CEST] <wbs> dash_fill_tmpl_params [11:38:09 CEST] <wbs> does exactly the same thing that the demuxer needs to do [11:38:23 CEST] <wbs> given a format string and the provided numbers, expand the format string [11:38:33 CEST] <wbs> without blindly passing the string into printf or something like that, that would be insane [11:38:43 CEST] <JEEB> :) [11:38:50 CEST] <wbs> yes, with the muxer, the only attack vector would be the command line user passing a weird option [11:39:01 CEST] <wbs> but despite that, I don't think there is any such vulnerability in the existing code in dashenc [11:39:14 CEST] <BtbN> Yeah, that function does indeed look very reusable [11:39:37 CEST] <wm4> the dash patch also duplicates some nasty code from hls [11:39:38 CEST] <wbs> and there's this huge argument on the mailing list, about how the reimplementation of this exact function should be, with or without potential vulenrabilities [11:39:50 CEST] <wm4> like trying to open segments with correct cookies/useragent [11:39:54 CEST] <BtbN> well, have you told them about the existence of that function? [11:40:03 CEST] <wm4> or this awful "security" bullshit that checks protocol names [11:40:03 CEST] <wbs> I have not, and I'm not going to enter into that mailing list thread [11:40:20 CEST] <wbs> if you care, you can point the masses to this function in dashenc.c, if not, let them keep arguing [12:21:00 CEST] <cone-221> ffmpeg 03Paras Chadha 07master:61e4db4bb730: Add FITS Decoder [12:21:01 CEST] <cone-221> ffmpeg 03Paras Chadha 07master:207f0cff2ac8: Add FITS Demuxer [12:21:02 CEST] <cone-221> ffmpeg 03Paras Chadha 07master:6e02f66f1bc7: Add FITS Encoder [12:21:03 CEST] <cone-221> ffmpeg 03Paras Chadha 07master:df475db9a29e: Add FITS Muxer [12:21:04 CEST] <cone-221> ffmpeg 03Paras Chadha 07master:9d99f0afbeed: FATE: Add FITS tests [12:21:05 CEST] <cone-221> ffmpeg 03Paul B Mahol 07master:a4d18a3f54e5: avfilter/vf_lut2: add framesync options [12:21:06 CEST] <cone-221> ffmpeg 03Paul B Mahol 07master:2b9fd157342f: avcodec/codec_desc: make FITS description longer [12:52:10 CEST] <arpu> a ffmpeg -re -stream_loop -1 -i testme.flv -c:v copy -an -f flv "rtmp://..." alwys stops after the eos of the file is reached with av_interleaved_write_frame(): Broken pipe [12:52:59 CEST] <arpu> verbose output http://lpaste.net/7901301616186228736 [12:53:08 CEST] <arpu> is this a bug? or i do something wrong? [14:07:55 CEST] Action: JEEB appreciates wm4's http://git.videolan.org/?p=ffmpeg.git;a=commit;h=463b81de2b252691d754176435… [14:09:18 CEST] <wm4> amusingly it got already broken by the float pixfmt additions [14:09:26 CEST] <JEEB> :D [14:09:49 CEST] <nevcairiel> how so? at least binary 0 is also float 0 :d [14:10:06 CEST] <nevcairiel> or are those yuv floats [14:10:11 CEST] <JEEB> I guess float YCbCr [14:11:09 CEST] <wm4> float are 4 bytes per component [14:11:18 CEST] <wm4> the code can handle only 2 bytes per component [14:11:46 CEST] <wm4> also, half-range yuv doesn't use 0 [15:24:19 CEST] <cone-221> ffmpeg 03Ashish Singh 07master:2a4a26fa4f3c: avfilter/vf_libvmaf: fix pre convert to framesync2 bugs [15:24:20 CEST] <cone-221> ffmpeg 03Ashish Singh 07master:1dc33c123715: configure: require pkg-config for libvmaf [15:33:11 CEST] <kierank> vis_mb_type is broke [15:48:26 CEST] <durandal_1707> kierank: isnt that done with codecview? [16:23:59 CEST] <kierank> durandal_1707: no [16:24:02 CEST] <kierank> mv is codecview [16:58:43 CEST] <JEEB> so do I see correctly that the AAC encoder could in theory handle !1024 nb_sample AVFrames since it has its own internal ff_af_queue, but the audio encoding framework requires AVFrame->nb_samples to be exactly AVCodecContext->frame_size? [16:59:24 CEST] <atomnuker> no [17:00:25 CEST] <JEEB> ok [17:00:43 CEST] <atomnuker> the afq only does packet timestamps and is sometimes used to calculate the last frame's skip samples [17:00:52 CEST] <atomnuker> (on some encoders) [17:01:15 CEST] <atomnuker> so its not a queue for the actual samples but for keeping track of the numer of samples in and out [17:01:43 CEST] <JEEB> ok [17:01:57 CEST] <JEEB> also there's that copy_input_samples thing, which seems to be some sort of a buffer [17:02:02 CEST] <JEEB> will have to see how big it is etc [17:02:14 CEST] <JEEB> ok [17:02:15 CEST] <JEEB> s->planar_samples[ch] = s->buffer.samples + 3 * 1024 * ch; [17:02:17 CEST] <JEEB> so yea [17:02:32 CEST] <JEEB> I will need to cut AVFrames from decoder/filtering to fit the nb_frames [17:02:51 CEST] <JEEB> somehow I hadn't cut myself with this yet [19:10:02 CEST] <cone-221> ffmpeg 03James Almer 07master:350dc01dcb80: fate: remove usage of deprecated AVCodecContext.me_method in vsynth snow tests [19:16:13 CEST] <cone-221> ffmpeg 03James Almer 07master:ec07574a15ba: fate: stop using deprecated filter syntax in hls tests [19:36:53 CEST] <cone-221> ffmpeg 03James Almer 07master:f7d4c60ac475: avfilter/vf_mcdeint: free the AVCodecContext struct properly [19:45:28 CEST] <cone-221> ffmpeg 03James Almer 07master:2b7da70a70fe: postproc: remove usage of deprecated QP_STORE_T define [20:26:37 CEST] <cone-221> ffmpeg 03Paul B Mahol 07master:6ccd32c36760: avfilter/af_adelay: remove requirement that at least one delay should be provided [00:00:00 CEST] --- Thu Aug 31 2017

1 0

ffmpeg.log.20170830
by burek 31 Aug '17

31 Aug '17

[00:11:09 CEST] <DHE> I usually say mp4 for industry codecs, mkv for anything that gives you trouble [00:30:58 CEST] <mozzarella> holyshit lol [00:31:15 CEST] <mozzarella> av_interleaved_write_frame(): No space left on device [00:31:22 CEST] <mozzarella> Conversion failed! [00:31:26 CEST] <mozzarella> all that for nothing [00:31:29 CEST] <mozzarella> I hate myself [00:42:16 CEST] <systemd0wn> Question, When FFmpeg constructs a RTMP packet, what is the value of the Timestamp field? Is this the system time when the packet was constructed? [00:42:34 CEST] <c_14> check the source code? [00:43:03 CEST] <systemd0wn> c_14: I looked around a bit but I'm not super savy with C. [00:57:37 CEST] <nicolas17> hmm I should write an AWS S3 protocol for ffmpeg [01:03:58 CEST] <nicolas17> does ffmpeg ever read from output files? or is all the data for eg. writing the moov atom kept in memory? [01:04:32 CEST] <nicolas17> (obviously -movflags faststart does read from the file, but that's a bit of a special case) [01:05:21 CEST] <c_14> numerous output formats require seeking [01:05:31 CEST] <c_14> non fragmented mp4 [01:05:35 CEST] <c_14> non streamable matroska [01:05:56 CEST] <nicolas17> a plain old mp4 will write to the file, and when it finishes it will seek to the beginning and write the header [01:06:18 CEST] <nicolas17> but does it need to *read*? or just writes to the beginning? [01:07:03 CEST] <nicolas17> faststart is a notable case where ffmpeg will have to read the file it just wrote again [01:08:41 CEST] <c_14> I think it won't read in most cases [01:08:43 CEST] <c_14> But I'm not sure [01:19:59 CEST] <nicolas17> bah nevermind [01:20:04 CEST] <nicolas17> I would need the ability to read anyway [01:21:51 CEST] <nicolas17> if ffmpeg seeks to the beginning and rewrites the first 100 bytes... I can't overwrite a chunk that small in S3, the minimum part size is 5MB, so I would need to read the existing contents first [01:22:21 CEST] <nicolas17> screw that, I'll make it read-only [01:27:05 CEST] <acos> Back. Now where was I [01:28:22 CEST] <dorvan> nicolas17: I've reduced to 5mbit/s and removed almost all optimization for mpeg-dash conversion on streamed input. at moment i have 38mbyte/s input stream and a fluent 5.x <6 sec delayed live (net cam have a native delay of 2sec) [01:29:13 CEST] <dorvan> nicolas17: profile it's high always, no vantages to downgrade it.. [01:30:58 CEST] <acos> What's a good format to avoid generation loss? What's a good format to merge many files into a single one? [01:33:10 CEST] <dorvan> acos: what do you need as output? a big file to see like a movie, or a live dynamic stream? [01:34:06 CEST] <dorvan> acos: at moment we record small .mp4 files for playback and a small and fast live stream with dash... [01:34:38 CEST] <dorvan> where, like to hls, you have a playlist of various files [01:35:12 CEST] <dorvan> acos: not a single monolithic file, but a playlist. [01:35:41 CEST] <acos> Well dorvan I'm editing a wedding video and am doing it part by part exporting each scene from an editor. Then I want to merge into a single file to send to my client. [01:36:26 CEST] <acos> I'm trying to avoid generation loss [01:37:05 CEST] <dorvan> acos: ah okay a totally different case, so you need to reorder single slices and merge a single video without recoding a full video? [01:37:49 CEST] <acos> That's the hope. But concat no work for me [01:38:37 CEST] <dorvan> source slices are all in the same format? what is the format? [01:39:01 CEST] <acos> Well it's h264 as an avi [01:40:30 CEST] <dorvan> i think you can use ffmpeg with params to avoid a reconding on live realtime streaming [01:41:16 CEST] <dorvan> simply the video it's read "as is" and sent to output (same format) [01:41:34 CEST] <acos> It complains about the audio. Source is mp3 and it wants aac [01:41:38 CEST] <klaxa> you mean -c copy? [01:42:21 CEST] <dorvan> klaxa: copy with preset to force the realtime... [01:43:42 CEST] <dorvan> klaxa: https://trac.ffmpeg.org/wiki/StreamingGuide [01:44:11 CEST] <dorvan> in this way, follow the logic, you have only to organize the input stream [01:45:03 CEST] <dorvan> klaxa: do you know if a playlist can be used as input directly? [01:45:08 CEST] <acos> Ohhh. I was following that concat guide trying to convert to a ts file then merge those. [01:45:28 CEST] <klaxa> you can use the concat demuxer [01:45:43 CEST] <klaxa> the playlist has to be in the format: file "somefile.mkv" for each file [01:45:59 CEST] <klaxa> then you can do: ffmpeg -f concat -i playlist.txt [whatever] output.mkv [01:46:01 CEST] <acos> It did not work klaxa [01:46:18 CEST] <acos> And it reszied my video to 1920x1088 [01:46:52 CEST] <dorvan> klaxa: acos have asked for something different :-) [01:47:13 CEST] <klaxa> huh, but you asked for the playlist thing [01:47:16 CEST] <klaxa> i'm confused [01:47:24 CEST] <dorvan> consider the request firstly :-) [01:47:27 CEST] <acos> :/ I'm hitting all the errors possible with this software. [01:47:35 CEST] <dorvan> yes... acos can't use concat... [01:47:52 CEST] <acos> Aww. Well at least I tried. [01:48:00 CEST] <dorvan> klaxa: acos does not want to use concat... [01:48:17 CEST] <acos> Also my videos have a green line on top and bottom of my video not sure why. [01:48:26 CEST] <dorvan> so i'm thinking a way to produce a single file for a multiple input.... [01:48:39 CEST] <klaxa> use the concat filter? [01:48:45 CEST] <dorvan> no [01:48:47 CEST] <dorvan> :-D [01:48:48 CEST] <klaxa> that needs re-encoding though [01:48:49 CEST] <acos> I will post logs in a bit. [01:49:00 CEST] <dorvan> oh fuc* [01:49:07 CEST] <klaxa> you can use a lossless codec to avoid quality loss [01:49:09 CEST] <dorvan> klaxa... without using concat... [01:49:33 CEST] <klaxa> so you want to concat without concat [01:49:36 CEST] <dorvan> klaxa: acos does not want to "re-convert" [01:49:42 CEST] <klaxa> there are two ways to concat [01:49:44 CEST] <dorvan> exactly:-D [01:49:59 CEST] <acos> Maybe my logs will help clarify the issue [01:50:02 CEST] <klaxa> one only works if the files have the same codec and codec parameters [01:50:07 CEST] <klaxa> the other is independent [01:50:13 CEST] <klaxa> but requires re-encoding [01:50:19 CEST] <acos> How can I force an output resolution ? [01:50:28 CEST] <klaxa> -s 1920x1080 [01:50:37 CEST] <klaxa> that will re-encode [01:50:44 CEST] <klaxa> if you use -c copy it will be ignored afaik [01:50:46 CEST] <dorvan> input (playlist) -> c:copy preset ultrafast lowlatency -> 1 file output :-) [01:51:02 CEST] <acos> Why would it change the resolution ? Some kind of x264 bug? [01:51:28 CEST] <dorvan> klaxa: resolution it's not included in acos question... can be a secondary problem [01:51:28 CEST] <klaxa> what is your command line? [01:51:51 CEST] <acos> Got 99 problems and a girl ain't one [01:51:55 CEST] <dorvan> acos... if you have all the slices in same and correct format you don't need to change resolution... [01:52:01 CEST] <dorvan> right? [01:52:11 CEST] <acos> It does it for me for some reason. [01:52:15 CEST] <dorvan> you have only to mount the movie... [01:52:18 CEST] <klaxa> codec options (i.e. preset ultrafast lowlatency) are ignored when using -c copy [01:52:29 CEST] <dorvan> not... [01:52:35 CEST] <dorvan> i have different results [01:52:38 CEST] <acos> Also it changed the frame rate to 28.6882828 [01:52:45 CEST] <acos> From 30 [01:53:03 CEST] <klaxa> what is your command line? [01:53:30 CEST] <acos> I will post in a bit. Computers off right now. Thanks for the help people ^_^ [01:53:31 CEST] <klaxa> afaict you have a bunch of clips you exported from some other program, right? [01:53:53 CEST] <klaxa> and you want to concatenate them into one file? [01:54:46 CEST] <klaxa> are you sure the program you use for exporting isn't messing something up already? [01:54:46 CEST] <dorvan> it's embedded in the our program since a week after some weeks on here to read the same things you are writing now.. [01:55:09 CEST] <dorvan> I've followed this https://trac.ffmpeg.org/wiki/StreamingGuide [01:55:29 CEST] <dorvan> and many other related topics on the web... [01:55:52 CEST] <klaxa> wait, how is this related to streaming? [01:55:52 CEST] <dorvan> also this https://sonnati.wordpress.com/ [01:55:56 CEST] <klaxa> or is that another problem? [01:56:02 CEST] <acos> klaxa: ya [01:56:02 CEST] <dorvan> yes :-) [01:56:09 CEST] <klaxa> it was an "or" question [01:56:12 CEST] <klaxa> "yes" is an invalid answer [01:56:23 CEST] <dorvan> klaxa: i'm happy i've not a problem, i've answering and trying to help acos... [01:56:47 CEST] <acos> klaxa: well yes videos from a program. They are exports. [01:56:49 CEST] <dorvan> i've asked to you 1 thing i don't know... and you are going around and around :-) [01:57:27 CEST] <klaxa> can you repeat that question? i'm really confused by you guys :P [01:57:31 CEST] <acos> Sorry. Not sure what to do. [01:57:38 CEST] <dorvan> acos: your video slices are all ready in the same format and all you need, right? you have only to merge up without make a recoding, right? [01:57:59 CEST] <acos> Yes? They are h264 video clips [01:58:18 CEST] <klaxa> if they really are the same format, the concat demuxer *should* work, however without output from ffmpeg no definite conclusion can be made [01:58:20 CEST] <dorvan> ok... you have to concat without using concat :-D [01:58:31 CEST] <dorvan> klaxa: you are a mirror [01:58:33 CEST] <acos> It gets mad about the audio not being acc [01:58:43 CEST] <klaxa> then use a different container [01:58:52 CEST] <acos> Not sure how. [01:58:53 CEST] <dorvan> ok... i go to bed ... [01:59:04 CEST] <klaxa> ffmpeg [input stuff] output.mkv [01:59:05 CEST] <acos> I'm new to ffmpeg command line [01:59:19 CEST] <klaxa> just specify the output file as something that ends in .mkv [01:59:27 CEST] <dorvan> good night acos, good night mr blinders [01:59:44 CEST] <acos> Night dorvan [01:59:51 CEST] <acos> Thanks for the help :) [02:00:15 CEST] <klaxa> whoops [02:00:17 CEST] <klaxa> bad touchpad [02:01:35 CEST] <dorvan> acos: if the solution of klaxa, does not match your problem (can be a good percentage...) looks to merge video as streaming input, without recoding. [02:02:47 CEST] <acos> Will do. Going to do some dishes then hop on the pc [02:06:26 CEST] <dorvan> acos: the klaxa tips can be good... https://stackoverflow.com/questions/11647868/using-ffmpeg-to-stream-continu… [02:07:39 CEST] <acos> Sounds great. :D [03:25:44 CEST] <redrabbit> what is a good interface/service for win10 to transcode a media library, music and videos [03:26:01 CEST] <redrabbit> i dont want something like plex [04:33:34 CEST] <mozzarella> guys [04:34:15 CEST] <mozzarella> when I reencode a video, it doesn't use hardware acceleration (i.e. my graphic card), right? [04:37:31 CEST] <c3r1c3-Win> Well... not unless you tell it to use whatever compressor your GPU has. [04:39:09 CEST] <Over> Hi, i'm having trouble with ffmpeg, and searching on google didn't solve my problem [04:40:53 CEST] <mozzarella> c3r1c3-Win: how do I do that? is it going to be faster? [04:41:59 CEST] <c3r1c3-Win> mozzarella: Faster? Depends. Better Quality at the same bitrate as x264@veryfast? No, at least not that I've ever seen. [04:45:11 CEST] <Over> Maybe someone can help me, so here is my problem, i'm using cuda to hw accelerate the encoding of a rtmp live stream, and when i want to apply filters to resize it, i get this : "Impossible to convert between the formats supported by the filter 'graph 0 input from stream 0:0' and the filter 'auto_scaler_0' [04:45:27 CEST] <c3r1c3-Win> mozzarella: How? Depends on your GPU. If you have an Intel look at the Quicksync option in ffmpeg. If you have an NVidia, look at the NVENC options. If you have an AMD... I think someone by the name of Xaymar is working on AMF support in ffmpeg, but don't quote me on that. [08:54:00 CEST] <igracia> morning! go a question related to padding a video with black frames to delay it, using vstack and hstack. I've managed to achieve this with overlay and setpts=PTS-STARTPTS+xx/TB, and yesterday c_14 suggested just concatenating black video. Thing is I'll be building a matrix of 16-25 videos, and 15-24 of them will have this offset. Is hstack+vstack+concat 16 videos more performant than overlaying 16 videos? [08:54:13 CEST] <igracia> Morning! got a question related to padding a video with black frames to delay it, using vstack and hstack. I've managed to achieve this with overlay and setpts=PTS-STARTPTS+xx/TB, and yesterday c_14 suggested just concatenating black video. Thing is I'll be building a matrix of 16-25 videos, and 15-24 of them will have this offset. Is hstack+vstack+concat 16 videos more performant than overlaying 16 videos? [08:54:31 CEST] <igracia> c_14: yesterday I lost connection, that's why I couldn't follow up [09:08:54 CEST] <thebombzen> igracia: overlay is much slower than hstack and vstack [09:12:21 CEST] <igracia> thebombzen: even with the generation+concatenation of 15 black color streams? Of course I cna always measure, but just checking here just in case it's not even worth measuring [09:12:50 CEST] <igracia> I can't reuse the same "color" filter output, right? [09:13:01 CEST] <thebombzen> generation of pure black is extremely easy [09:13:29 CEST] <thebombzen> the overlay filter is slow, and if you can avoid using it you should [09:14:16 CEST] <thebombzen> I mean, to generate pure black you basically just have to zero out memory. that's not hard [09:34:21 CEST] <igracia> thebombzen: thanks a lot! [09:59:01 CEST] <mozzarella> guys [09:59:06 CEST] <mozzarella> hello [10:04:20 CEST] <tadau> hi [10:04:49 CEST] <tadau> are there no keys defined to adjust volume in ffplay? [10:07:31 CEST] <JEEB> don't try to use ffplay as a real player; utilize something like mpv or libmpv as a player based on the FFmpeg libraries :) [10:42:42 CEST] <taniey> can ffplay get multiple input? [10:49:40 CEST] <BtbN> thebombzen, zeroing out memory gives you green though [10:50:13 CEST] <BtbN> getting black, with yuv, is slightly more complex [10:50:23 CEST] <JEEB> I think wm4 added a function for that [10:50:43 CEST] <JEEB> it went into libav at least, probably ffmpeg too [10:50:58 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=463b81de2b252691d754176435… [10:51:01 CEST] <JEEB> yup [10:51:32 CEST] <JEEB> > Common cases like yuv420p10 or RGBA can't be handled with a simple memset [11:48:32 CEST] <dragmore> so im trying to test my Nvidia 1070GTX for cuvid encoding, anyone got some examples where one can see the profile, preset, scenecut usage etc? [11:49:45 CEST] <BtbN> cuvid is a decoder. nvenc is the encoder [11:52:37 CEST] <dragmore> btbn, sorry, i mean nvenc [11:53:16 CEST] <BtbN> Can always consult ffmpeg -help encoder=nvenc [11:54:06 CEST] <dragmore> nvenc is h264, is the same one used for HEVC ? [11:54:19 CEST] <JEEB> I think the encoders are separate [11:54:22 CEST] <JEEB> nvenc_hevc or so? [11:54:27 CEST] <BtbN> hevc_nvenc [11:54:30 CEST] <JEEB> ight [11:54:33 CEST] <BtbN> as h264_nvenc is the h264 one [11:54:47 CEST] <dragmore> yupp thats the one [11:54:50 CEST] <BtbN> They are essentially the same encoder though. Sharing 99% of the code [11:55:25 CEST] <BtbN> And don't expect wonders from the hevc encoder. It's not very good [11:55:31 CEST] <dragmore> i knwo [11:55:38 CEST] <dragmore> its for some realtime projects [11:55:52 CEST] <JEEB> you'd probably get better results from realtime AVC :D [11:55:54 CEST] <dragmore> 2160p50 8bit source material [11:55:56 CEST] <JEEB> in either SW or HW [11:56:03 CEST] <BtbN> You might be better off sticking with h264 for those. Way better compatiblity. [11:56:17 CEST] <dragmore> target is our STB (uhd main10 decode) [11:56:27 CEST] <JEEB> right [11:57:04 CEST] <BtbN> As stupid as it sounds: For video encoding jobs with nvenc, a 1050 or 1050 Ti is the better choice, if you don't need the GPU power of a 1070. [11:57:06 CEST] <dragmore> im just curious if ffmpeg+nvenc can deliver something thats watchable at all ;) [11:57:23 CEST] <dragmore> 1070 is what i have here infront of me ;) [11:57:26 CEST] <JEEB> BtbN: it's not stupid, it's called "they share an ASIC" [11:57:46 CEST] <BtbN> the 1050 has a better, more modern, ASIC than the 1060 and higher [11:57:51 CEST] <JEEB> oh [11:57:52 CEST] <JEEB> funky [11:57:58 CEST] <dragmore> whats the relationship with the cudacores and the nvenc asic part? [11:58:01 CEST] <BtbN> Because it was the last card to be released [11:58:06 CEST] <JEEB> dragmore: not really much [11:58:11 CEST] <BtbN> nvenc/cuvid is dedicated silicon [11:58:17 CEST] <JEEB> ASIC is a separate component on the thing [11:58:19 CEST] <BtbN> the GPU is not involved with it at all [11:58:21 CEST] <dragmore> does the nvenc "encoder" use cuda at all for some parts of the work? [11:58:26 CEST] <dragmore> ok [11:58:41 CEST] <BtbN> Some of the post-processing features of cuvid use cuda [11:58:45 CEST] <BtbN> like deinterlacing and scaling [11:58:55 CEST] <JEEB> even GPU manufacturers noticed that the kool-aid was not gonna help GPGPU encoding [11:59:01 CEST] <dragmore> well this is source = destination regards to resolution, framerate etc [11:59:20 CEST] <dragmore> any reccomended settings for RT 25fps? [11:59:45 CEST] <BtbN> the slowest one you can find [12:00:02 CEST] <BtbN> so, just put slow there, and let the automatism do its job [12:00:13 CEST] <dragmore> -preset slow -profile main10 -level 5 [12:00:18 CEST] <dragmore> what rate control method? [12:00:25 CEST] <BtbN> no need to specify a level, unless you are constrained [12:00:36 CEST] <dragmore> box can handle 5.1 main10 [12:00:59 CEST] <BtbN> yeah, restrict it to 5.1 then [12:01:09 CEST] <BtbN> rate control is up to you [12:01:23 CEST] <dragmore> -rc cbr_ld_hq -b 25000 would prolly suffice [12:01:26 CEST] <BtbN> if you don't care about the bitrate, just use constqp for a constant quality [12:01:47 CEST] <dragmore> im allowed a max of 30mbps [12:01:50 CEST] <BtbN> cbr is generally the worst choice quality wise [12:01:59 CEST] <dragmore> but for Realtime encoding [12:02:20 CEST] <BtbN> I'd still stick with vbr_hq and specify a maxrate [12:02:25 CEST] <dragmore> this is prolly gonna be SMTE 2022-6 input and RTP multicast out [12:03:04 CEST] <dragmore> SMPTE 2022-6 sorry [12:03:12 CEST] <BtbN> the only difference between cbr and vbr is that cbr inserts NULL-NAL-Units to fill up to the given bitrate [12:03:28 CEST] <BtbN> between cbr and vbr + maxrate [12:03:50 CEST] <BtbN> If you need the strict static bitrate, cbr_hq [12:03:51 CEST] <dragmore> is there a "skewed realtime" mode for 2 pass vbr? [12:03:56 CEST] <BtbN> hm? [12:03:59 CEST] <dragmore> with increased latency [12:04:10 CEST] <BtbN> nvenc does not have classic two pass [12:04:15 CEST] <BtbN> It's some weird internal thing. [12:04:19 CEST] <dragmore> i was just thinking the other day, can one let the encoder to multiple passes within the VBV buffer [12:04:31 CEST] <BtbN> you can just always turn it on. It just makes it slightly slower [12:05:01 CEST] <BtbN> I guess you are looking for -rc-lookahead? [12:05:27 CEST] <dragmore> well.. im a newb here.. so i dont know ;) [12:05:36 CEST] <dragmore> but this is my offline h264 encoding [12:05:37 CEST] <dragmore> "ffmpeg -i source.mp4 -pix_fmt yuv420p -codec:v libx264 -x264opts rc-lookahead=50:keyint=100:min-keyint=50:crf=24 -profile high -level 4.1 -preset slow -maxrate 7M -bufsize 14M -force_key_frames "expr:eq(mod(n,50),0)" -c:a copy -y AiB_HQ_3.mp4" [12:05:57 CEST] <dragmore> something like that, just for Realtime and hevc using nvenc [12:06:41 CEST] <dragmore> i need to force an IDR frame each gop (2 sec) and give the encoder a scenecut ability to insert an iframe where neded [12:07:06 CEST] <BtbN> I don't think you can do that with ffmpeg.c [12:07:25 CEST] <BtbN> There is no interface to dynamically insert an I frame [12:07:41 CEST] <dragmore> well it works with x264 [12:07:48 CEST] <BtbN> How do you signal it? [12:07:52 CEST] <BtbN> There is no interface for that [12:07:54 CEST] <dragmore> as my syntax above, ffprobe confirms it [12:08:35 CEST] <dragmore> i get an IDR frame every 50fps [12:08:49 CEST] <dragmore> and additional iframes when there is a hard scene change [12:08:50 CEST] <BtbN> That's just the gop length [12:08:59 CEST] <BtbN> And there is some automatic scenecut detection if you use lookahead [12:09:21 CEST] <dragmore> yes, (i just found it on the net).. so i dont understand it completely [12:09:32 CEST] <dragmore> but from the export in ffprobe, it seem to work [12:12:01 CEST] <dragmore> so the syntax for hevc would be something like : ffmpeg input -rc vbr_hq -level 5.1 -profile main10 -preset slow -pix_fmt yuv420p -codec:v hevc_nvenc output [12:12:58 CEST] <dragmore> how does one specify the max bitrate for -rc ? [12:13:12 CEST] <dragmore> -rc vbr_hq -maxrate 40000 ? [12:14:49 CEST] <BtbN> -b:v for the average bitrate, and -maxrate:v for the maxrate [12:15:12 CEST] <BtbN> Setting a -bufsize:v might also be a good idea [12:15:45 CEST] <dragmore> ok [12:15:47 CEST] <dragmore> ffmpeg -i AiB_GoT_Master4-2-2_1080p-IMX-2chWAV.mkv -rc vbr_hq -b:2000 -maxrate:4000 -bufsize:4000 -level 5.1 -profile main10 -preset slow -rc-lookahead=50 -pix_fmt yuv420p -codec:v hevc_nvenc test.ts [12:16:27 CEST] <dragmore> forgot the encoder ;) [12:16:29 CEST] <dragmore> ffmpeg -i AiB_GoT_Master4-2-2_1080p-IMX-2chWAV.mkv -c:v hevc_nvenc -rc vbr_hq -b:2000 -maxrate:4000 -bufsize:4000 -level 5.1 -profile main10 -preset slow -rc-lookahead=50 -pix_fmt yuv420p -codec:v hevc_nvenc test.ts [12:16:33 CEST] <BtbN> and that whole -force_key_frames thing looks just like -g 50 to me? [12:16:57 CEST] <dragmore> Unrecognized option 'rc-lookahead=50'. [12:17:17 CEST] <BtbN> the = does not belong there [12:17:46 CEST] <dragmore> ffmpeg -i AiB_GoT_Master4-2-2_1080p-IMX-2chWAV.mkv -c:v hevc_nvenc -rc vbr_hq -b:2000 -maxrate:4000 -bufsize:4000 -level 5.1 -profile main10 -preset slow -rc-lookahead 50 -pix_fmt yuv420p -codec:v hevc_nvenc test.ts [12:17:52 CEST] <dragmore> [NULL @ 00000000028833c0] Unable to find a suitable output format for '5.1' 5.1: Invalid argument [12:18:50 CEST] <BtbN> It thinks 5.1 is your output filename [12:19:13 CEST] <BtbN> The : is also wrong [12:19:19 CEST] <BtbN> It's always a space [12:19:24 CEST] <BtbN> and it's -b:v and -maxrate:v [12:19:32 CEST] <dragmore> ffmpeg -i AiB_GoT_Master4-2-2_1080p-IMX-2chWAV.mkv -c:v hevc_nvenc -rc vbr_hq -b:2000 -maxrate:4000 -bufsize:4000 -level 5.1 -profile main10 -preset slow -rc-lookahead 50 -pix_fmt yuv420p -codec:a copy -f test.ts [12:19:54 CEST] <BtbN> I'd also recommend dropping the -pix_fmt entirely [12:20:05 CEST] <BtbN> and if the input is h264, you can utilize full hw transcoding [12:20:12 CEST] <dragmore> problem is that the source is 4:2:2 [12:20:19 CEST] <dragmore> mpeg2 xdcam as source [12:20:28 CEST] <BtbN> hm, yeah. That won't work with hw decoding then [12:21:26 CEST] <dragmore> hmm [12:21:27 CEST] <dragmore> ffmpeg -i AiB_GoT_Master4-2-2_1080p-IMX-2chWAV.mkv -c:v hevc_nvenc -rc vbr_hq -b:2000 -maxrate:4000 -bufsize:4000 -level 5.1 -profile main10 -preset slow -rc-lookahead 50 -pix_fmt yuv420p -codec:a copy -f test.ts [12:21:54 CEST] <dragmore> still : Unable to find a suitable output format for '5.1' 5.1: Invalid argument [12:25:33 CEST] <dragmore> ffmpeg -i AiB_GoT_Master4-2-2_1080p-IMX-2chWAV.mkv -c:v hevc_nvenc -rc vbr_hq -b:v 2000 -maxrate:v 4000 -bufsize:v 4000 -level 5.1 -profile:v main10 -preset slow -rc-lookahead 50 -pix_fmt yuv420p -c:a copy -f test.ts [12:25:36 CEST] <dragmore> getting closer [12:28:33 CEST] <dragmore> hehe [12:28:34 CEST] <dragmore> [hevc_nvenc @ 00000000026a3d40] No NVENC capable devices found [12:28:39 CEST] <dragmore> ffmpeg crashed [12:29:12 CEST] <dragmore> even if ffmpeg -help encoder=hevc_nvenc gave me an output [12:31:52 CEST] <dragmore> "[hevc_nvenc @ 0000000002797020] Loaded Nvenc version 8.0 [hevc_nvenc @ 0000000002797020] Nvenc initialized successfully [hevc_nvenc @ 0000000002797020] 1 CUDA capable devices found [hevc_nvenc @ 0000000002797020] [ GPU #0 - < GeForce GTX 770 > has Compute SM 3.0 ] [hevc_nvenc @ 0000000002797020] Codec not supported [hevc_nvenc @ 0000000002797020] No NVENC capable devices found" [12:32:06 CEST] <dragmore> ffs.. wrong gfx card ;) [13:07:33 CEST] <BtbN> That last commandline looks fine. Only missing the -g 50 for the gop length [13:47:56 CEST] <dystopia_> hevc encoding doesnt seem viable yet [13:48:01 CEST] <dystopia_> sooo slooow :( [13:48:14 CEST] <JEEB> and very few care about the format it seems [13:48:17 CEST] <JEEB> at least in open source [13:48:22 CEST] <JEEB> so decoding isn't optimized, either [13:50:34 CEST] <BtbN> blame the patent crazyness around it [13:50:46 CEST] <BtbN> And it just is a very complex codec. It will always be somewhat slow [13:52:00 CEST] <JEEB> in encoding, yes [13:52:16 CEST] <JEEB> comparatively to AVC that is [13:52:23 CEST] <JEEB> decoding wise it should be on similar level as VP9 if someone put some love into it [13:52:35 CEST] <BtbN> hw decoding for it is quite widespread by now [13:52:39 CEST] <JEEB> yea [14:14:26 CEST] <charly> Hello [14:14:33 CEST] <charly> I have a live TS stream containing closed captions [14:14:41 CEST] <charly> How to burn them into the decoded video ? [14:15:08 CEST] <JEEB> which type of CCs? [14:15:33 CEST] <charly> eia608 [14:18:12 CEST] <JEEB> charly: when you demux packets for the track that can have CCs, check for side data packets with CCs. then if found, open a decoder for the format and create an AVPacket of the side data => feed to decoder => get text => render text with libass or something on top of the video => done [14:18:19 CEST] <JEEB> it's contrived but possible :P [14:21:06 CEST] <charly> ok so as i supposed, ass & subtitles filters can't operate with live streams ? [14:21:28 CEST] <JEEB> why not? it's just that I don't think there's any AVFilters that take in subtitles :D [14:22:08 CEST] <JEEB> charly: so you get an RGB overlay from libass, and then you can overlay that with the overlay avfilter [14:22:09 CEST] <JEEB> whether or not you're live or not doesn't really matter does it :P [14:23:57 CEST] <charly> ok, i will use libass. Thank you ! [14:24:42 CEST] <JEEB> good luck [16:54:40 CEST] <blap> libass needs fixing :/ [16:55:14 CEST] <blap> putting new subs up at 'random' lines on the screen is unreadable, for multiline/overlapping subs [17:03:44 CEST] <JEEB> I think the rendering order depends on the order of entry [17:32:30 CEST] <thatandyrose> hey there! total n00b here. Can anyone help with a question or shall I just ask? [17:33:55 CEST] <DHE> IRC rule is to read the topic, then just ask according to whatever rules the topic has provided [17:34:59 CEST] <thatandyrose> thanks DHE... sorry, first time on IRC. Basically I have this ffmpeg related question: https://stackoverflow.com/questions/45964212/how-to-merge-two-audio-files-w… [17:35:35 CEST] <thatandyrose> If my question is inappropriate or I'm asking in an inappropriate way do let me know [17:48:10 CEST] <durandal_1707> thatandyrose: perhaps you neeed asetpts filter, hard to guess without input files [17:50:29 CEST] <thatandyrose> @durandal_1707 thank you for the heads up. You know what... I think my question is flawed. When do `ffmpeg -i 1audio.m4a` I see that start is not at 0... it's at 5... I don't quite get this.... but, is there a way to merge two audio files which take into account non 0 start positions? [17:50:55 CEST] <thatandyrose> sorry, typo. It should be "When I do ffmpeg..." [17:52:19 CEST] <durandal_1707> thatandyrose: then you need adelay filter with parameters that will add silence samples so start matches [17:53:50 CEST] <thatandyrose> @durandal_1707 hmm can you point me to an example? I'll start googling now but if you know of a good one let me know. Another option is to pad each file so they start at 0 right? how would I do that? [17:54:44 CEST] <durandal_1707> adelay pads audio at beginning [17:54:57 CEST] <durandal_1707> apad filter pads at end [17:59:08 CEST] <thatandyrose> cool, thanks @durandal_1707, I'll start taking a look at those. Thanks for your help! [17:59:35 CEST] <durandal_170> thatandyrose: something like: ffmpeg -i first.mp4 -i second.mp4 -lavfi "[0:a]adelay=5000|5000[a],[a][1:a]amerge" [18:00:01 CEST] <durandal_170> 5000|5000 says to delay each channel to 5 seconds [18:02:53 CEST] <thatandyrose> hmm thanks @durandal... ok, I gotta figure out how I get the delay first as I need this to be programmatic with dynamic input. #killmenow [18:04:10 CEST] <durandal_170> thatandyrose: delays is first pts of first input minus first pts of second input [19:26:55 CEST] <idlus> Hello, isn't it possible to chain two chromakey filters? It seems that only the last one is in effect. [19:28:25 CEST] <durandal_1707> idlus: of you need 2 you are doing something wrong [19:28:56 CEST] <durandal_1707> -vf chromakey,chromakey [19:30:16 CEST] <idlus> I'll paste my filter chain, hope it's not too long [19:30:26 CEST] <idlus> [vid1] split=2 [jeu][cam]; [jeu] crop=.65*iw:.86*ih:.065*iw:.01*ih [jeu]; [cam] crop=.21*iw:.23*ih:.75*iw:.75*ih, chromakey=black,chromakey=blue, scale=-1:ih, [jeu] overlay=0:main_h-overlay_h [vo] [19:30:56 CEST] <BtbN> it's probably not exactly black or not exactly blue [19:31:17 CEST] <idlus> if I use either one individually it works as I expect [19:31:43 CEST] <idlus> eg the black region or the blue region is filtered out, but when chained only the blue is in effect [19:31:51 CEST] <durandal_1707> chromakey only modifies alpha [19:32:09 CEST] <BtbN> Well, it will overwrite the alpha channel [19:32:17 CEST] <idlus> oh ok [19:32:17 CEST] <BtbN> so it kind of makes sense only the last one is "active" [19:32:30 CEST] <idlus> sure, how can I combine them then [19:32:31 CEST] <idlus> ? [19:32:39 CEST] <BtbN> Don't think you can [19:32:51 CEST] <durandal_1707> yes just merge alphas [19:33:01 CEST] <durandal_1707> its complicated [19:34:06 CEST] <idlus> so maybe another filter branch with alphamerge? [19:34:17 CEST] <BtbN> alphamerge does not just merge two alpha channels [19:34:21 CEST] <durandal_170> split[a][b],[a]chromakey=black[a],[b]chromakey=blue[b],[a][b]blend=c3_mode=and... [19:35:23 CEST] <durandal_170> this will create union of two alpha channels [19:36:21 CEST] <idlus> ok, never used "blend" before, I'll read up on it and test your solution [19:36:24 CEST] <idlus> thank you both [20:09:56 CEST] <nicolas17> how do I stop ffplay from disabling my desktop compositor? [20:10:09 CEST] <nicolas17> I lose window transparency and shadows while ffplay is running [20:10:25 CEST] <JEEB> don't use ffplay if you want a player based on FFmpeg's libraries: mpv is much preferred [20:10:33 CEST] <JEEB> it is an actual player while ffplay is a Proof of Concept [20:11:56 CEST] <nicolas17> I made a 4fps timelapse with ffmpeg and I'm watching the result with ffplay just because vlc seems to get an inconsistent framerate [20:27:02 CEST] <alexpigment> hey guys, I'm trying to make a patch that adds "coder" (cabac vs cavlc) to NVENC. i'm extremely green on the source code, but here's what I see in libx264.c: https://ffmpeg.org/doxygen/3.0/libx264_8c_source.html (line 974) [20:27:51 CEST] <alexpigment> and here's what I see in nvEncodeAPI.h https://www.ffmpeg.org/doxygen/3.2/nvEncodeAPI_8h_source.html (line 570) [20:28:31 CEST] <JEEB> note: that's from 3.2, if you want latest that's "trunk" (or you just use git.videolan.org to browse) [20:28:39 CEST] <alexpigment> I'm wondering if I can copy what's shown in libx264 into nvenc.c , but I'm not sure what parameters need to reference what's shwn in nvEncodeAPI.h [20:29:06 CEST] <JEEB> also I have no idea if nvenc even lets you set CAVLC or CABAC [20:29:25 CEST] <JEEB> well, OK - baseline profile requires CAVLC IIRC [20:29:33 CEST] <JEEB> so it has to have it around [20:29:47 CEST] <alexpigment> the API says you can set it [20:30:04 CEST] <alexpigment> but it's not hooked up in FFMPEG's nvenc in any way that I can tell [20:30:10 CEST] <alexpigment> the coder parameter is certainly ignored [20:30:22 CEST] <alexpigment> but the API exposes it, which you can see in nvEncodeAPI.h [20:30:49 CEST] <JEEB> ok, then you just limit the parameter according to valid values in init() [20:30:59 CEST] <JEEB> of the libavcodec thing you want [20:31:10 CEST] <JEEB> and then set the value accordingly in nvenc's API [20:31:15 CEST] <alexpigment> I've transplanted the code from libx264.c into nvenc.c , but I just am not sure how to hook up the specific parameters from the API [20:31:47 CEST] <BtbN> also needs a proper capability check if the hardware even supports CABAC [20:31:56 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=compat/nvenc/nvEncodeAPI.h;h… [20:32:55 CEST] <alexpigment> I don't think there are any nvenc-capable cards that dont' support cabac, although I understand it's safer to check [20:33:31 CEST] <JEEB> huh, I thought coder was a global avcodec option but the vaapi thing actually defined the AVOption there [20:33:34 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=c6a8c2a4f7396c4524a081df8a… [20:33:45 CEST] <JEEB> (it has more values most likely because it supports more than AVC) [20:33:46 CEST] <alexpigment> it's global, but it isn't hooked up for nvenc [20:34:15 CEST] <JEEB> then I wonder why vaapi wrapper got it implemented in the way it got [20:34:25 CEST] <JEEB> because you can see it definining those AVOoptions [20:34:53 CEST] <JEEB> if it's just available in AVCodecContext then (Ž4@) [20:35:13 CEST] <BtbN> probably so it shows up in help [20:35:40 CEST] <BtbN> I wish there was some kinda mechanism to declare "I use this global option" [20:35:47 CEST] <BtbN> which then makes it show up in -help for that encoder. [20:35:51 CEST] <jkqxz> This one, with all the deprecation guards around it? <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/avcodec.h;h=51323…> [20:35:59 CEST] <alexpigment> BtbN, i would be a big fan of that [20:36:48 CEST] <JEEB> jkqxz: ah ok [20:36:59 CEST] <JEEB> I had no idea it was being deprecated in favour of encoder-specific AVOptions [20:37:03 CEST] <JEEB> but then it makes sense :) [20:37:05 CEST] <jkqxz> I didn't actually look at when it was deprecated, but the private option matches libx264. [20:37:36 CEST] <alexpigment> for what it's worth, I'm just trying to address a bug I logged up a while back: https://trac.ffmpeg.org/ticket/6475 [20:37:50 CEST] <alexpigment> there's no deprecation warning, at least the last time I tested [20:39:14 CEST] <BtbN> there definitely is one now [20:39:54 CEST] <jkqxz> Commit was <http://git.videolan.org/?p=ffmpeg.git;a=commit;h=be00ec832c519427cd92218aba…>, apparently. Makes sense, I guess. [20:40:44 CEST] <jkqxz> alexpigment: There is just no warning in general for common options which aren't actually used. [20:42:16 CEST] <jkqxz> And that isn't really a very easy thing to change. Every codec would need to declare the set of options they care about and then there could be some common code to check whether any of them are specified and warn. [20:44:19 CEST] <jkqxz> And if they only use them in some modes but not others then that becomes even more complicated. [20:44:37 CEST] <alexpigment> honestly, i'm not really picky about global vs encoder-specific options [20:44:39 CEST] <BtbN> well, only warn if they do declare [20:44:43 CEST] <BtbN> so the transition can go slowly [20:44:49 CEST] <alexpigment> I just need it to be hooked up [20:44:59 CEST] <alexpigment> fwiw, it's certainly not deprecated for x264 as a global option [20:45:08 CEST] <alexpigment> no warnings [20:45:13 CEST] <jkqxz> x264 is a private option as well. [20:45:57 CEST] <jkqxz> <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/libx264.c;h=b11ed…> [20:46:12 CEST] <alexpigment> ok, so you'll have to pardon my ignorance on how this all works. everything I log on trac is ignored, so I'm trying to about addressing things and I know nothing about programming or the inner workings of ffmpeg [20:46:33 CEST] <BtbN> I haven't seen anything about this option missing on trac [20:46:34 CEST] <alexpigment> all I'm trying to do is to get CAVLC encoding in nvenc via ffmpeg [20:46:36 CEST] <alexpigment> and it is not hooked up [20:46:46 CEST] <BtbN> what even is that? I never heard that term before. [20:47:08 CEST] <alexpigment> BtbN: are you being facetious? [20:48:19 CEST] <alexpigment> well, I'll assume you aren't. it's "context-adaptive variable-length coding", as opposed to cabac = "context-adaptive binary arithmetic coding" [20:48:19 CEST] <BtbN> what? [20:49:12 CEST] <alexpigment> cavlc is requires much less processing power and is commonly used on intra-frame formats in NLEs [20:49:49 CEST] <BtbN> Does HEVC have something similar, or is it h264 only? [20:50:03 CEST] <alexpigment> if HEVC has it, I'm not aware [20:50:25 CEST] <jkqxz> HEVC does not have any non-arithmetic coder, no. [20:50:40 CEST] <JEEB> HEVC decided to drop CAVLC [20:50:43 CEST] <JEEB> it's CABAC only [20:51:03 CEST] <alexpigment> yeah, HEVC is already processor intensive enough that they probably didn't see much merit in a coding mode that was easier to process [20:52:16 CEST] <sikilikis> hey all. How do I get the "fontfile" parameter to work when using the drawtext filter? It seems to be completely ignored. The font never changes and if I provide a bogus filepath to it, ffmpeg happily ignores it anyway [20:58:08 CEST] <sikilikis> the text gets drawn but I can't change the font being used [21:00:47 CEST] <jkqxz> BtbN: Um, ffmpeg probably shouldn't segfault if you try to use h264_nvenc without any hardware, right? [21:01:04 CEST] <jkqxz> alexpigment: This work? <http://sprunge.us/ZbMH> (Not actually tested.) [21:01:15 CEST] <BtbN> It should just tell you that it found no GPU. Or just straight up failed to load the cuda libs [21:03:07 CEST] <jkqxz> Apparently not <http://sprunge.us/QSEZ>. [21:04:01 CEST] <jkqxz> It shouldn't be trying to call that context function if there is no cuda at all, I guess? [21:10:53 CEST] <alexpigment> jkqxz: sorry, was away [21:11:25 CEST] <alexpigment> when you said "Apparently not" were you saying that the patch didn't work, or were you replying the BtbN? [21:12:29 CEST] <alexpigment> BtbN: actually, I know someone who ran into that same thing, although I had no explanation. I figured he just had some driver debris sitting around [21:12:41 CEST] <BtbN> The crash? [21:12:44 CEST] <alexpigment> Yeah [21:12:55 CEST] <BtbN> That's just an oversight when adding context pushes everywhere [21:12:56 CEST] <jkqxz> That was to the crash. First patch might work. [21:13:00 CEST] <alexpigment> They started getting the crash with a build from late June [21:13:27 CEST] <alexpigment> OK [21:13:29 CEST] <alexpigment> Testing this out now [21:14:03 CEST] <alexpigment> Thank you very much. I would have never known that I needed to make changes to all 3 files [21:16:20 CEST] <BtbN> https://github.com/BtbN/FFmpeg should have fixes for both [21:18:06 CEST] <alexpigment> Awesome. Testing now [21:18:34 CEST] <BtbN> no idea how to determine if that coder mode works or does anything though [21:19:08 CEST] <alexpigment> really it's just specifying coder 0 and seeing if MediaInfo reports it as CABAC still [21:19:08 CEST] <jkqxz> Run it through the trace_headers BSF and look for entropy_coding_mode_flag in the PPS. [21:19:21 CEST] <alexpigment> if coder 0 creates a CABAC file, it's not working ;) [21:19:38 CEST] <BtbN> coder 0 is auto, which will produce whatever nvenc likes [21:19:49 CEST] <alexpigment> really? [21:19:53 CEST] <BtbN> yes [21:19:58 CEST] <alexpigment> OK, well, i'll use the appropriate command [21:20:07 CEST] <alexpigment> x264 has coder = cavlc [21:20:20 CEST] <alexpigment> a little confusing when switching between the two, but not a huge deal I suppose [21:20:30 CEST] <BtbN> I keps the names consistent for a reason [21:20:33 CEST] <BtbN> *kept [21:20:42 CEST] <alexpigment> sorry, i meant to say coder = 0 is cavlc in x264 [21:20:42 CEST] <BtbN> The numerical values are arbitrary [21:21:25 CEST] <alexpigment> well, they are certainly arbitrary, although you'd like their meanings to stay the same when switching between two encoders [21:21:43 CEST] <BtbN> nvenc and x264 are diffrent. Can't make them match up perfectly [21:22:15 CEST] <alexpigment> I agree with you, but you also don't want the behavior to be the opposite [21:22:31 CEST] <BtbN> The opposite? [21:22:36 CEST] <alexpigment> At any rate, I can work with this and change the code accordingly so that coder 0 does cavlc [21:22:49 CEST] <BtbN> Just use the const name, it's there for that reason [21:22:50 CEST] <alexpigment> nvenc is probably always going to do cabac when set to auto [21:32:03 CEST] <alexpigment> coder now working for NVENC :) [21:32:08 CEST] <alexpigment> awesome work [21:32:18 CEST] <alexpigment> checking the other patches I made now [21:33:08 CEST] <alexpigment> jkqxz: to clarify, I tested your patch [21:33:30 CEST] <alexpigment> coder 0 produces CAVLC and coder 1 produces CABAC, perfectly matching x264 [21:34:56 CEST] <BtbN> do not use the numerics [21:35:02 CEST] <BtbN> they are arbitrary [21:35:09 CEST] <BtbN> and can change without notice [21:35:35 CEST] <alexpigment> BtbN: honestly, if you saw how many tutorials and stackoverflows and the like on google that specifically mention coder 0, you might think differently [21:35:38 CEST] <alexpigment> this is not about me [21:35:51 CEST] <BtbN> There are a lot of bad "guides" out there, yes. [21:35:52 CEST] <DHE> doesn't make it right [21:35:58 CEST] <alexpigment> this is about making sure that the information on the internet remains applicable [21:36:08 CEST] <BtbN> It never was applicable in the first place [21:36:12 CEST] <alexpigment> it certainly was [21:36:15 CEST] <BtbN> It's a const option. You are supposed to use the name. [21:36:17 CEST] <alexpigment> It was 100% applicable [21:36:26 CEST] <alexpigment> The guides specifically are referring to x264 [21:36:40 CEST] <BtbN> It's the same for libx264 [21:36:52 CEST] <alexpigment> What I'm saying is that it's preferable to maintain parity with x264 since it's another encoder that produces the same output format [21:36:59 CEST] <alexpigment> what is the same? [21:37:14 CEST] <BtbN> It maintains perfect parity with x264. As it uses the exact same constants. [21:37:59 CEST] <alexpigment> then why are you insisting that I not use constants? [21:38:07 CEST] <BtbN> Because you are not. [21:38:15 CEST] <alexpigment> sorry [21:38:17 CEST] <alexpigment> constants [21:38:17 CEST] <alexpigment> yes [21:38:24 CEST] <alexpigment> lemme rephrase [21:38:35 CEST] <alexpigment> why are you insisting that I not use numerics [21:38:44 CEST] <BtbN> Because they are not part of the API [21:38:51 CEST] <BtbN> And can change without notice [21:39:21 CEST] <alexpigment> look, just google "ffmpeg cabac" [21:39:22 CEST] <alexpigment> first result [21:39:27 CEST] <alexpigment> it will tell you to use coder 0 [21:39:37 CEST] <alexpigment> that's very powerful and important [21:39:42 CEST] <BtbN> And wrong [21:39:48 CEST] <alexpigment> the first result is spreading "misinformation" according to you [21:39:50 CEST] <alexpigment> but it works for libx264 [21:39:54 CEST] <alexpigment> to this day it works [21:40:05 CEST] <alexpigment> if coder 0 can work for nvenc, it should [21:40:32 CEST] <BtbN> I'm not going to make this code more complicated to cater to bad answers someone gave on stackoverflow. [21:40:44 CEST] <alexpigment> it's the old saying about software companies. if microsoft has a bug that affects your software, *it's your bug* [21:40:58 CEST] <BtbN> The numerics are not part of the API for libx264 either. [21:41:05 CEST] <alexpigment> BtbN: you don't need to. jkqxz already did this in his patch [21:41:19 CEST] <BtbN> His patch does not expose the auto option nvenc has [21:41:43 CEST] <DHE> http://ffmpeg.org/ffmpeg-codecs.html#Options-25 libx264 does not list 0 and 1 as valid options to the 'coder' parameter [21:41:43 CEST] <alexpigment> what is the point of auto? [21:42:07 CEST] <BtbN> It lets nvenc automatically decide which mode to use [21:43:29 CEST] <alexpigment> if you specify profile baseline and set the coder to auto, what happens? [21:43:45 CEST] <BtbN> Don't know. That's driver-internal. [21:43:50 CEST] <DHE> it will adhere to the baseline limitations [21:44:13 CEST] <alexpigment> ok, so if you don't specify coder auto and set it to baseline, what happens? [21:44:24 CEST] <BtbN> It will use the value the preset declares [21:44:48 CEST] <alexpigment> then I guess it brings me back to the question of "what is the point of auto"? [21:45:13 CEST] <BtbN> It's what the API declares. So if a preset defines something else, you can override it. [21:45:24 CEST] <alexpigment> if setting the profile automatically changes the coding mode, then there is really no point in additionally specifying that the coder should be set to auto [21:45:43 CEST] <alexpigment> in theory, you would only ever specify the coder when you know that the auto is going to be the opposite of what you want [21:45:48 CEST] <DHE> it's also possible that using a preset will override any settings that conflict with it. but again that's driver dependent [21:47:26 CEST] <alexpigment> at any rate, I've got something working now, and I appreciate all the work being done here. I was really just trying to make sure that we could keep parity with x264 in terms of all the information that is readily available on the internet [21:47:39 CEST] <BtbN> There is perfect parity with x264 [21:47:42 CEST] <BtbN> The public API matches [21:47:47 CEST] <BtbN> except that nvenc has one additional option [21:48:56 CEST] <alexpigment> BtbN: you said that coder 0 is auto rather than cavlc [21:49:04 CEST] <alexpigment> that is the nonparity i'm talking about [21:49:21 CEST] <BtbN> The numeric values are arbitrary [21:49:35 CEST] <BtbN> cabac or ac is cabac, cavlc or vlc is cavlc. [21:49:43 CEST] <alexpigment> I get your point, but please step back from being a developer for once second [21:49:44 CEST] <BtbN> Exactly the same as for libx264 [21:49:50 CEST] <alexpigment> google: ffmpeg "coder 0" [21:49:54 CEST] <alexpigment> 28,600 results [21:50:01 CEST] <alexpigment> now google ffmpeg "coder vlc" [21:50:03 CEST] <alexpigment> 128 results [21:50:14 CEST] <alexpigment> that should tell you that you kinda have to just give in to the masses [21:50:19 CEST] <BtbN> again, I'm not going to cater to wrong guides or answers. If we started doing that, ffmpeg would be one hell of a mess [21:50:26 CEST] <alexpigment> especially considering your assignment of 0 to auto is arbitrary [21:50:43 CEST] <BtbN> I did not make any assignments, except defining -1 as undefined [21:50:54 CEST] <BtbN> everything else just comes from the nvEncodeApi header [21:51:59 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=compat/nvenc/nvEncodeAPI.h;h… [21:53:01 CEST] <alexpigment> I see what you're saying [21:53:13 CEST] <alexpigment> I don't think you see what I'm saying [21:53:37 CEST] <BtbN> I see what you're saying. I just plain disagree. [21:54:19 CEST] <alexpigment> BtbN: Most developers probably would. Anyone in QA or customer-facing positions would not. [21:54:22 CEST] <JEEB> it's the same thing as all of those recommendations of strict -2 (experimental) breaking if the internal values happen to change for one reason or another (except it was evn mentioned in a message which is d'uh) [21:55:33 CEST] <alexpigment> Well sure, but any developer probably recognizes that strict -2 is being used rampantly in the wild and won't change it [21:55:39 CEST] <alexpigment> I would hope so at least [21:55:51 CEST] <BtbN> If there is a good reason to change it, it would be changed. [21:56:11 CEST] <alexpigment> BtbN: And that's why people don't update open source software often [21:56:33 CEST] <alexpigment> I know people in professional environments who won't upgrade their copy of Linux unless they absolutely have to [21:56:37 CEST] <JEEB> also since the option is being added to a new thing it makes even less sense to try and match internal values between sub-libraries headers since the strings are the thing you're supposed to be using [21:56:55 CEST] <alexpigment> JEEB: did you see my example about the google search results? [21:57:16 CEST] <alexpigment> I know you guys are developers, but surely you can see from the end user point of view to *some* degree, right? [21:57:19 CEST] <JEEB> yes, and that's quite unfortunate. but are any of those about this specific encoder? [21:57:52 CEST] <alexpigment> No, but that doesn't stop people from having something that works, then trying to port over their code to a similar encoder [21:58:26 CEST] <alexpigment> I'm sure when you try to learn another programming language, you hope things here and there match up so you don't have to unlearn what you know from the other language [21:58:29 CEST] <iive> so you are saying that we should forbid this option from taking a number at all [21:58:38 CEST] <JEEB> iive: that sounds like a good idea [21:58:50 CEST] <JEEB> the thing is rather incidental anyways :P [21:59:49 CEST] <alexpigment> I guess I just don't see you guys have such a case of developer-brain that my logic isn't seeping in at all [22:00:16 CEST] <JEEB> there are cases where doing things for compatibility's sake makes sense [22:00:27 CEST] <alexpigment> Either way, jkqxz made a great patch, and so I've got something that works fine right now [22:00:56 CEST] <iive> btw, why do you want cavlc again? [22:01:13 CEST] <alexpigment> AVC Intra, NLE usage [22:01:34 CEST] <alexpigment> takes out decoding hit, especially at higher bitrates [22:01:43 CEST] <iive> so low quant, high bitrates? [22:01:47 CEST] <alexpigment> right [22:01:54 CEST] <JEEB> in this case it most definitely doesn't given how this is a new option added for a new encoder (Thus guides do not point at it) and generally if people utilize internal values and expect them to be *globally* the same then derp [22:02:09 CEST] <JEEB> just like you'd expect all encoders have the same preset values as libx264 [22:02:16 CEST] <iive> alexpigment: does it really help, aka have you benchmarked it? [22:02:54 CEST] <JEEB> also I think the most hilarious thing would be if the values are mapped to nvidia header values and then *nvidia* changed the internal values they'd point at :P [22:02:58 CEST] <alexpigment> iive: I trust that the experts at Adobe, Panasonic, etc have done those benchmarks for me and that's why they use it [22:03:04 CEST] <JEEB> pffft [22:03:23 CEST] <JEEB> just look at how panasonic, sony etc fucked "AVC Intra" [22:03:35 CEST] <iive> if you can benchmark, then do benchmark [22:03:57 CEST] <JEEB> > ISO/IEC standard > companies make proprietary and non-standard versions of it (that cannot be decoded with a standard decoder often) [22:04:10 CEST] <JEEB> > put out a public spec and an NDA'd implementation thing [22:04:14 CEST] <iive> because i've heard that cavlc makes low quants so huge, that the cache misses ruin the benefit of the simpler computation. [22:04:16 CEST] <JEEB> > the two don't match [22:04:33 CEST] <JEEB> anyways, CAVLC's effect depends really [22:04:56 CEST] <alexpigment> Why do I feel like every time I come here I'm dealing with a bunch of overworked and underpaid developers? I'm not here to defend international standards. I'd just like to follow what's out there because I don't go out of my way to reinvent to wheel [22:04:59 CEST] <JEEB> depends on if you use more CPU running through the extra bits, or if you shave off time by the means of CAVLC being faster [22:05:23 CEST] <JEEB> alexpigment: it's because you say as if those corporations always do their decisions based on cold facts and objective measures [22:05:38 CEST] <alexpigment> JEEB: again, I'm not trying to defend them. that's not my job [22:05:46 CEST] <JEEB> yea, your comment was just funny :P [22:05:53 CEST] <JEEB> but do note I actually commented about CAVLC [22:05:58 CEST] <iive> alexpigment: we are saying, that you have to do the benchmarks on your own. [22:06:10 CEST] <iive> their assemstments might be just obsolete [22:06:24 CEST] <alexpigment> I don't have to do benchmarks. All I came here to do was to make sure that a parameter in the NVENC API was actually hooked up [22:06:37 CEST] <iive> maybe at the time the cabac hasn't been optimized [22:06:38 CEST] <JEEB> I generally tend to utilize something like Ut Video for NLE and if I absolutely need to use something non-lossless then libx264 with up to 3 frame or so GOP [22:07:14 CEST] <JEEB> I think dw made some benchmarks for seeking speed etc some years ago [22:07:33 CEST] <JEEB> as in, how big of a GOP you can have with H.264 to start having a delay in seeking in NLE-like use cases [22:08:02 CEST] <alexpigment> Does it really matter though? I'm just trying to match a standard, not see how far I can get away from the standard before it starts to affect performance [22:08:12 CEST] <JEEB> sure [22:08:20 CEST] <alexpigment> So this conjecture is pointless to me [22:08:45 CEST] <alexpigment> You want AVC Intra, you set the GOP to 1 and the encoding type to CAVLC [22:08:54 CEST] <JEEB> although I'm actually surprised nvenc can output "AVC Intra" looking at how fucked up the panasonic stuff is [22:09:07 CEST] <JEEB> hard-coded parameter sets that you cannot write into the bit stream [22:09:08 CEST] <JEEB> etc [22:09:15 CEST] <alexpigment> Well, this is certainly a case of "let's get as close as we can" [22:09:25 CEST] <JEEB> ok, so you're not doing actual "AVC Intra" [22:09:29 CEST] <JEEB> but just intra AVC [22:09:31 CEST] <JEEB> ;) [22:09:32 CEST] <BtbN> it probably can't perfectly. But good enough to be accepted by some specific player/software [22:09:36 CEST] <alexpigment> NVENC's interlace handling is currently fucked, so that's another issue entirely [22:09:50 CEST] <alexpigment> well, FFMPEG's implementation of nvenc's interlace handling, to be clear [22:09:52 CEST] <BtbN> It's supposedly fixed in recent enough drivers. [22:10:01 CEST] <BtbN> The ffmpeg side of it is fine. [22:10:07 CEST] <BtbN> The driver wasn't [22:10:14 CEST] <alexpigment> BtbN: I've got an open issue about it still [22:10:25 CEST] <BtbN> with nvidia? [22:10:29 CEST] <alexpigment> no, with ffmpeg [22:10:31 CEST] <BtbN> where? [22:10:35 CEST] <alexpigment> I compared it with Staxrip [22:11:07 CEST] <alexpigment> sorry, looking for the ticket now [22:11:13 CEST] <BtbN> There really isn't a lot to it from the ffmpeg side. [22:11:23 CEST] <Sgt_Tailor> Hey, I was wondering if it is possible to add a new input to ffmpeg while it is running and add it to a complex_filter as well. I know you can send commands to filters to change the positions of layers in the complex filter, but I've been unable to find anything about adding more inputs on the fly [22:11:28 CEST] <BtbN> If it does something subtly wrong, it's most likey in the driver [22:11:46 CEST] <BtbN> Sgt_Tailor, it's not that flexible unfortunately. [22:11:56 CEST] <BtbN> So, no, not possible. [22:12:55 CEST] <alexpigment> BtbN: https://trac.ffmpeg.org/ticket/5818 [22:12:59 CEST] <alexpigment> see my last comment [22:13:02 CEST] <alexpigment> that was from 2 months ago [22:13:22 CEST] <alexpigment> I haven't checked back in since then, but I think the driver update you're talking about was from earlier this year [22:13:28 CEST] <Sgt_Tailor> Hmm, can you point me in the direction of something that does allow me to do that BtbN(Excluding OBS because it has no cli or api I can program against) [22:14:00 CEST] <BtbN> obs has an api [22:14:14 CEST] <BtbN> All its functionality is in libobs, and the ui just uses that lib itself [22:14:28 CEST] <BtbN> And it's really the best(and only) thing I know for that job. [22:14:55 CEST] <Sgt_Tailor> holy balls, thanks! Not sure how I missed that [22:16:52 CEST] <BtbN> alexpigment, that ticket is quite old. Interlaced Encoding by now works. If you are using the latest nvidia driver [22:17:04 CEST] <BtbN> I think it was 384? [22:17:24 CEST] <BtbN> https://devtalk.nvidia.com/default/topic/976088/video-technologies/ffmpeg-h… [22:17:30 CEST] <BtbN> 375.39 [22:17:34 CEST] <alexpigment> Yes, I remember this thread [22:17:51 CEST] <alexpigment> In that example, they're getting combing artifacts [22:18:17 CEST] <alexpigment> Now what happens is that there's no combing, but each field in a frame is from the same timestamp [22:18:32 CEST] <alexpigment> Either way, I'll double check now that it's been 2 months since I last checked it [22:23:34 CEST] <alexpigment> BtbN: same problem [22:23:40 CEST] <alexpigment> https://trac.ffmpeg.org/ticket/6260 [22:23:59 CEST] <alexpigment> if you try the "how to reproduce" code with the interlacedsample.mp4, you'll see the problem [22:24:09 CEST] <alexpigment> x264 creates a smooth 60i video [22:24:28 CEST] <alexpigment> nvenc creates a choppy video that looks the same as if it were 30p [22:26:27 CEST] <alexpigment> now of course, you're going to have to use a player that correctly deinterlaces from 60i to 60p (i.e. not VLC) [22:30:08 CEST] <alexpigment> I tested with 384.76 for what it's worth. However, the important part is that the encode works in Staxrip's NVENC implementation, but not FFMPEG's, so I don't believe this has anything to do with the driver at this point [22:38:12 CEST] <azarus> What's faster to encode vp8/9 video with, VDPAU or VAAPI (AMD R9 Fury / Intel i5-6600K)? [22:38:32 CEST] <BtbN> vdpau is a decoder [22:38:42 CEST] <BtbN> And I don't think vaapi can encode either of them [22:39:45 CEST] <azarus> BtbN: https://stackoverflow.com/questions/26000606/how-do-you-get-ffmpeg-to-encod… [22:39:58 CEST] <azarus> Seems on new platforms hw encode is supported. [22:40:37 CEST] <jkqxz> VP8 will work on the Intel but not the AMD. VP9 won't work on either. [22:40:58 CEST] <BtbN> Does ffmpeg even implement the vaapi vp8 encoder? [22:41:34 CEST] <azarus> jkqxz: And hw encode is almost always faster, right? [22:41:43 CEST] <BtbN> you trade speed for quality [22:42:05 CEST] <azarus> BtbN: Still a massive gain in efficiency. [22:42:15 CEST] <BtbN> depends [22:42:23 CEST] <BtbN> if you need twice the bitrate for comparable quality [22:43:42 CEST] <azarus> BtbN: At least it doesn't take hours for simple and short videos -.- [22:44:16 CEST] <BtbN> if it takes hours for simple and short videos with libvpx, something is very wrong [22:47:11 CEST] <azarus> Just a slow proc, and [22:47:19 CEST] <azarus> maybe wrong cmdlind options. [22:47:21 CEST] <BtbN> slow proc, that has vp8 hw encoding? [22:47:35 CEST] <azarus> Well... Was doing it on a different proc before. [22:48:12 CEST] <azarus> Once on a i7-2600 and once on a Core 2 Duo P8600. [22:48:21 CEST] <azarus> Now I'll try on a CPU with hw encode. [22:48:33 CEST] <BtbN> that i7 should be more than capable [22:49:05 CEST] <azarus> Ehh, still too slow. It was about 2x as fast than the P8600 though. [22:49:13 CEST] <azarus> faster* [23:00:43 CEST] <alexpigment> BtbN: I don't suppose you have any interest in looking into why NVENC interlacing is broken, right? [23:00:54 CEST] <alexpigment> I know there's another developer who tackles all the hardcore NVENC stuff [23:01:24 CEST] <BtbN> It's 11pm. I don't have much interest to look into anything at the moment. [23:01:33 CEST] <BtbN> But I'll definitely look at it [23:01:51 CEST] <alexpigment> That's fine. You asked about it earlier, so I didn't know if that meant you were interested [23:02:15 CEST] <alexpigment> Anyway, do you thing. I do appreciate all your help, even if we disagree about a few specifics :) [23:02:19 CEST] <alexpigment> *do your thing, rather [23:31:09 CEST] <BtbN> jkqxz, could you test if that patch fixes the crashing? I'm fairly confident it does, but don't want to push it untested. And I don't have any machines without nvidia GPUs [23:34:55 CEST] <jkqxz> ? The one I sent to the ML earlier works for me. [23:35:12 CEST] <jkqxz> Or do you mean something else? [23:47:20 CEST] <alexpigment> so I tried to patch h264_nvenc so that it accepts -level 52 as a valid parameter [23:47:56 CEST] <alexpigment> but now that I do that, ffmpeg crashes and I get an error that says "Value 52.000000 for paramter 'level' out of range [0 - 51]" [23:48:22 CEST] <alexpigment> are the valid parameters defined outside of nvenc_h264.c? [23:49:28 CEST] <alexpigment> nvEncodeAPI.h shows NV_ENC_LEVEL_H264_52 as being an option [23:49:39 CEST] <alexpigment> I figured I could just add that option to nvenc_h264.c as well [23:50:07 CEST] <jkqxz> There is an upper bound in the "level" parameter as well as needing to add the 5.2 value at the end of the list. [23:50:58 CEST] <jkqxz> Third to last element in the initialiser on the line <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/nvenc_h264.c;h=5f…>. [23:51:27 CEST] <alexpigment> yeah, I just added a line after 70 [23:52:00 CEST] <alexpigment> with 5.2 at the beginning instead of 5.1, then I changed the NV_ENC_LEVEL_H264_52 at the end [23:52:02 CEST] <kepstin> alexpigment: you have to update the max on line 47 as well [23:52:22 CEST] <alexpigment> ahhh [23:52:25 CEST] <alexpigment> good eye kepstin [23:52:27 CEST] <alexpigment> I didn't see that one [23:53:18 CEST] <alexpigment> Seems weird that it's falsely limited to 5.1, but oh well [23:53:51 CEST] <kepstin> probably 5.2 was added later and nobody got around to updating it. Once you've done the patch, consider submitting it? [23:54:20 CEST] <alexpigment> I'll have to familiarize myself with the process, but sure [23:55:25 CEST] <kepstin> I suppose there isn't usually any reason to set the level to the max supported, of course, since usually the only thing setting level does is apply additional limits [23:56:02 CEST] <alexpigment> it's a completely fair point. I'm only really doing this because it currently gives a fatal error [23:56:22 CEST] <alexpigment> sure, no need to do it, but you can't error out on something the encoder supports (and will automatically assign in the right scenarios) [23:57:48 CEST] <kepstin> i dunno how exactly the nvenc coded works, but with x264 if you set a level that's higher than actually needed, it'll ignore it and save the real, lower level in the file. [23:58:01 CEST] <alexpigment> yeah, that sounds about right [23:58:05 CEST] <kepstin> in the file metadata [23:58:16 CEST] <kepstin> or stream metadata or whatever [23:58:49 CEST] <alexpigment> the nvenc thing is just like [encoding parameters + -level 52] = fatal error. [encoding parameters without -level 52] = no error, ends up setting level to 5.2 anyway [23:59:20 CEST] <alexpigment> kepstin: actually, now that I think of it, I think x264 lets you set dumb levels regardless of the need to do so [00:00:00 CEST] --- Thu Aug 31 2017

1 0

ffmpeg-devel.log.20170829
by burek 30 Aug '17

30 Aug '17

[00:05:33 CEST] <gh0st__> Huh, is that serious, the korean missile launch? [00:06:41 CEST] <nevcairiel> serious as in it happened? yes, apparently. serious as in will it have consequences? We shall see. [00:08:21 CEST] <gh0st__> nevcairiel: I am a little terrified now. [00:09:05 CEST] <nevcairiel> i'm just somewhat happy to live outside of their range [00:09:37 CEST] <kierank> i am happy we have an independent nuclear deterrent [00:10:14 CEST] <gh0st__> I live in siberia and I am not sure if that is outside of their range, probably not. [00:10:30 CEST] <kierank> wow siberia [00:10:33 CEST] <nevcairiel> as if deterrents stop people like NK [00:10:48 CEST] <gh0st__> yep [00:13:38 CEST] <gh0st__> Well, our television is not broadcasting about the north korean missile launches. [00:16:46 CEST] <gh0st__> I am thinking that if north korea launched nuclear missiles, consequences shall see all of the world. [00:17:32 CEST] <nevcairiel> it was probably another test without a warhead [00:17:49 CEST] <nevcairiel> but still quite taunting to have it fly over japan [00:21:37 CEST] <BBB> as for swr vs. avr, swr is faster (I wrote the assembly for the pieces that I know to be faster) [00:22:17 CEST] <BBB> I agree that the lack of public review for large components like that is troubling, and a mere manifestation of a much bigger problem [00:24:56 CEST] <atomnuker> all patches to swr I've seen in my time have been on the ML [00:25:18 CEST] <jamrial_> he's talking about how it landed [00:25:35 CEST] <jamrial_> every api change after the first commit made it to the ml [00:25:48 CEST] <jamrial_> it's old history anyway [00:25:53 CEST] <BBB> thats true [00:26:25 CEST] <BBB> anyway, I dont care about swr, it works for stuff I need it to do, I wrote some simd for it, I believe its significantly faster than avr for the same tasks [00:26:29 CEST] <BBB> so & next? [00:26:48 CEST] <BBB> I would mind more if it were video-related, where I have actual opinions about how it should work because I know something about it :-p [00:27:14 CEST] <nevcairiel> you should write us a new sws! [00:27:34 CEST] <kierank> I still need to get my field caption patch in [00:27:39 CEST] <kierank> maybe we can discuss at vdd [00:28:03 CEST] <gh0st__> What's sws? [00:28:16 CEST] <nevcairiel> swscale [00:29:14 CEST] <gh0st__> thanks! [00:33:42 CEST] <gh0st__> Also, vdd is a conference where all the guru of multimedia technologies gather to discuss the vector of the development of new technologies in multimedia? [00:34:22 CEST] <kierank> videolan.org/videolan/events/vdd17/ [00:37:03 CEST] <Compn> gh0st__ : open source multimedia projects gather to discuss [00:37:37 CEST] <atomnuker> still no schedule, wiki page for it was deleted 3 weeks ago :/ [00:37:48 CEST] <gh0st__> Wow, this is interesting. [00:38:35 CEST] <kierank> atomnuker: it's august in frane [00:38:42 CEST] <kierank> france [00:39:50 CEST] <atomnuker> yeah, they should enjoy it [00:40:09 CEST] <gh0st__> What do usually open source multimedia projects discuss? [00:40:28 CEST] <atomnuker> codecs [00:40:46 CEST] <atomnuker> though its mostly containers and streams outside of vdd [00:41:37 CEST] <gh0st__> What about "ground-breaking" stuff? [00:43:23 CEST] <atomnuker> those would be codecs [00:45:23 CEST] <gh0st__> Woah, I'd like to hear where codecs strive to. [00:48:36 CEST] <kierank> gh0st__: you should register [00:49:39 CEST] <atomnuker> its 4 days after the deadline to get sponsored though :/ [00:53:54 CEST] <gh0st__> Kierank: heh, I really have consider to attend this kind of conference, since it's going to be really fun =) [00:55:16 CEST] <atomnuker> I think you need a visa to visit the EU, right? [00:55:40 CEST] <gh0st__> atomnuker: yes, you are right. [00:56:03 CEST] <kierank> seems so [00:57:03 CEST] <gh0st__> That's a sad thing, not sure if I will get when the conference starts. [00:57:58 CEST] <gh0st__> Too much bureaucracy. [00:59:57 CEST] <durandal_1707> vdd is for old folks waiting death [01:02:39 CEST] <gh0st__> durandal_1707: new blood is always needed to drive this codec world somewhere, right? [01:03:28 CEST] <BBB> nevcairiel: believe it or not, I had a design for a new sws (I called it avs :-p these were very old times) a long time ago [01:03:34 CEST] <BBB> nevcairiel: I may still have it somewhere on my hd [01:03:56 CEST] <BBB> nevcairiel: but in the end I decided I didnt care enough, after all I use gl for scaling to display, who needs a software scaler anyway [01:04:29 CEST] <BBB> gh0st__: yes, were were all new blood at some point ;) [01:04:38 CEST] <BBB> gh0st__: and I agree, you should try to join [01:04:55 CEST] <durandal_1707> gh0st__: vdd is not relevant, multimedia is not relevant anymore [01:05:08 CEST] <BBB> so doomsday, dudio [01:05:13 CEST] <BBB> lighten up [01:05:43 CEST] <gh0st__> durandal_1707: why so? [01:06:20 CEST] <BBB> hes just trolling, ignore it [01:06:21 CEST] <atomnuker> gh0st__: all development happens on the internet mostly nowadays [01:06:30 CEST] <atomnuker> this is just for presenting [01:07:13 CEST] <durandal_1707> why vdd must be in france? [01:07:55 CEST] <atomnuker> 2015's venue was nice and they had nice breakfast and they served pizzas on the last day and there were pizzas leftover for everyone [01:08:27 CEST] <gh0st__> durandal_1707: I am not qualified enough to answer this, but why not? [01:09:09 CEST] <durandal_1707> gh0st__: multimedia is dead mostly because nothing big new comes around [01:09:14 CEST] <kierank> durandal_1707: you're in eu, what's the issuse [01:09:26 CEST] <kierank> durandal_1707: what big do you want [01:09:37 CEST] <durandal_1707> vdd is vlc folks and some lost souls [01:10:22 CEST] <durandal_1707> kierank: i dont like travel [01:10:30 CEST] <atomnuker> take the train then [01:10:38 CEST] <atomnuker> everyone likes train travel [01:11:04 CEST] <atomnuker> if you can get a train to switzerland somewhere you could take a tgv to paris [01:11:47 CEST] <durandal_1707> my mommy doesnt allow me to be outside after 22h [01:12:40 CEST] <durandal_1707> so i prefer teleportation [01:12:44 CEST] <atomnuker> you can go out at 0:00 and take a sleeper train [01:12:50 CEST] <atomnuker> 0:00 > 22:00 so you win [01:12:58 CEST] <durandal_1707> until then [01:13:07 CEST] <gh0st__> durandal_1707: I think there are left some BIG ideas around multimedia, that's what I am interested in. [01:13:09 CEST] <atomnuker> erm 22:00 < 0:00 so its before [01:13:53 CEST] <atomnuker> gh0st__: sure, av1 has big ideas (and daala is still the future imo) [01:14:04 CEST] <durandal_1707> gh0st__: yea like fractals in video coding [01:14:47 CEST] <durandal_1707> i need to finish clearvideo decoder [01:14:49 CEST] <TD-Linux> I'll be talking about the worst AV1 encoder ever (and no it's not libaom) [01:14:56 CEST] <durandal_1707> and atrac9 [01:15:09 CEST] <atomnuker> if you can think of a forward and reverse 2d transforms to get into a fractal domain you can use fractals [01:15:28 CEST] <atomnuker> (don't tell this to google) [01:16:02 CEST] <gh0st__> durandal_1707: I am rookie in multimedia world, but I think there a lot of great ideas unexplored. [01:16:14 CEST] <BBB> durandal_1707: if you need your mommys permission to go to stuff, then maybe you shouldnt attend indeed... [01:16:28 CEST] <BBB> anyway [01:16:35 CEST] <BBB> TD-Linux: wait, theres more than one AV1 encoder? [01:16:41 CEST] <TD-Linux> on an entirely serious note: fractal compression is dead http://www.geoffdavis.net/papers/ieee.pdf [01:17:59 CEST] <TD-Linux> BBB, there is one on my hard drive. my goal is to beat prores by VDD :^) [01:18:11 CEST] <BBB> can you guys start merging experiments in libaom so I know whats in and out? [01:18:21 CEST] <BBB> right now I cant write a serious encoder because everything is an experimental flag [01:18:31 CEST] <TD-Linux> yes, said encoder only hits a git snapshot [01:18:39 CEST] <BBB> thats ok [01:18:52 CEST] <BBB> but I need to know what features to approximately target for the final version [01:19:00 CEST] <BBB> but even features very likely to get in are experiments [01:19:03 CEST] <BBB> and so are things already rejected [01:19:10 CEST] <BBB> that list seriously needs some cleaning up (or documenting) [01:19:17 CEST] <TD-Linux> the default configuration is your best bet right now, but yes it does [01:19:18 CEST] <BBB> too many experiments" [01:20:03 CEST] <BBB> and may I also recommend someone not a daily dev doing some sort of bitstream analysis to find problems like the duplicate delta q coding etc? [01:20:10 CEST] <BBB> I really dont think thats very professional [01:20:54 CEST] <atomnuker> the secondary delta-q coding is even more useless now [01:21:00 CEST] <atomnuker> because 128x128 superblocks [01:21:02 CEST] <TD-Linux> well at least that problem is known [01:21:18 CEST] <BBB> o o 128x128 SBs? finally [01:21:28 CEST] <BBB> thats nice, I was hoping you guys would add that [01:21:32 CEST] <BBB> are there 128x128 transforms? [01:21:36 CEST] <atomnuker> nope [01:21:41 CEST] <BBB> probably for the better [01:21:44 CEST] <TD-Linux> only 32x32 enabled right now [01:21:48 CEST] <atomnuker> not even 64x64 yet [01:21:52 CEST] <BBB> 64x64 would be nice [01:21:56 CEST] <atomnuker> (and I really want 64x64) [01:22:05 CEST] <TD-Linux> we would like 64x64, but they will likely have coefficients dropped (like daala does) [01:22:14 CEST] <durandal_1707> no groundbreaking news [01:22:56 CEST] <atomnuker> TD-Linux: the new coefficient coding schemes might make full 64x64 transforms work better [01:23:19 CEST] <atomnuker> so there might not be a need to drop coeffs [01:23:34 CEST] <BBB> why drop coeffs? [01:23:46 CEST] <TD-Linux> well the reason to drop coeffs is mostly to drop a portion of the transform [01:23:59 CEST] <BBB> I understand what it does [01:24:01 CEST] <BBB> but why do that? [01:24:05 CEST] <BBB> for hw? [01:24:10 CEST] <TD-Linux> it makes software faster too. [01:24:29 CEST] <gh0st__> durandal_1707: I'd love to speak about groundbreaking stuff [01:24:30 CEST] <BBB> only in theory; in practice most coefficients beyond the first few are zero (quantized) anyway [01:24:30 CEST] <TD-Linux> atomnuker, a different coding scheme probably doesn't too much. coding an EOB sooner isn't very expensive [01:24:54 CEST] <BBB> what scenario are you worried about [01:24:55 CEST] <durandal_1707> gh0st__: first invent some [01:25:00 CEST] <TD-Linux> BBB, right, I guess on the decoder I guess you could pick between transform impls based on coeff values. [01:25:10 CEST] <BBB> you worry about the 6000th coefficient being 1 after quantization? [01:25:19 CEST] <BBB> right [01:25:23 CEST] <BBB> the decoder really isnt an issue here [01:25:31 CEST] <BBB> I think youre worried about lines of code in the fwd transform [01:25:34 CEST] <BBB> which is a fair transform [01:25:36 CEST] <atomnuker> TD-Linux: well if its optional (e.g. EOB) then it'll be great, lets encoders pick what they'd like to do in case they think its better [01:25:50 CEST] <TD-Linux> BBB, conversely, if it's not going to happen, why support it? :) [01:25:50 CEST] <BBB> but I thought you guys had transforms that were modeled after each other (i.e. the bigger calls the smaller) [01:26:10 CEST] <BBB> TD-Linux: its _unlikely_ to happen; it may, though [01:26:12 CEST] <atomnuker> yes, they're now an experiment [01:26:15 CEST] <atomnuker> and they're awesome [01:26:23 CEST] <BBB> and I love _love_ ___LOVE___ writing simd for these kind of things [01:26:34 CEST] <BBB> takes forever, but thats where you get actual speed gains [01:26:51 CEST] <BBB> (dont forget ffvp9 is 30% faster in practice, not in theory, and this is part of why) [01:27:10 CEST] <atomnuker> transform simd is the best [01:27:16 CEST] <BBB> Im willing to bet a bottle of wine that ffaom can be made faster then libaom also [01:27:20 CEST] <durandal_1707> then do same to ffhevc [01:27:23 CEST] <gh0st__> durandal_1707: What would one recommend to learn/study to better understand codecs? My guesses are: linear algebra, mathematics in general. [01:27:37 CEST] <BBB> durandal_1707: why you just said its dead :-p [01:27:48 CEST] <atomnuker> gh0st__: practice, and read a few code bases, math doesn't help you much at all [01:27:48 CEST] <BBB> durandal_1707: Im not contributing to dead technology [01:28:18 CEST] <TD-Linux> BBB, you'd be hard pressed to find someone to make that bet with :) [01:28:25 CEST] <durandal_1707> gh0st__: math is abstraction of ideas [01:29:09 CEST] <BBB> hm ok [01:29:47 CEST] <BBB> has the bit coder been decided? [01:29:54 CEST] <BBB> (the arithmetic coding) [01:30:02 CEST] <TD-Linux> yes, it's the one in the tree [01:30:09 CEST] <BBB> and that won change anymore? [01:30:10 CEST] <durandal_1707> why is ffhevc dead? folks still use it for whatever reason [01:30:23 CEST] <TD-Linux> BBB, nope [01:30:53 CEST] <BBB> TD-Linux: is it rANS? or something else? [01:31:00 CEST] <TD-Linux> BBB, it's daala's range coder [01:31:22 CEST] <BBB> how does adaptivity work? [01:31:36 CEST] <BBB> is it integrated like cabac or is it external? and if external, how often and based on what? [01:31:41 CEST] <TD-Linux> it adapts per symbol as well as propagating probs per frame [01:31:54 CEST] <BBB> fw update? [01:32:00 CEST] <durandal_1707> why not take that coder and make faster than ffv1 codec at same compression ratio? [01:32:13 CEST] <TD-Linux> no compressed header [01:32:23 CEST] <BBB> right, thats fw [01:32:30 CEST] <TD-Linux> yeah I forget which is which [01:32:30 CEST] <BBB> bw is replaced by per-symbol update [01:32:39 CEST] <BBB> and thats maintained between frames right? [01:32:42 CEST] <TD-Linux> yes [01:32:46 CEST] <BBB> good, good [01:32:49 CEST] <BBB> ok, I can start with that [01:32:51 CEST] <BBB> cool [01:32:51 CEST] <TD-Linux> all tile CDFs are merged at the end of the frame [01:32:56 CEST] <TD-Linux> for the bw update [01:33:18 CEST] <BBB> average? [01:34:23 CEST] <BBB> and so base block size is 128x128& thats easy also. and I guess from there on its just recursive partitioning except the partition choices are larger than in vp9 [01:35:11 CEST] <cone-927> ffmpeg 03Carl Eugen Hoyos 07master:d4fbe99dabe7: lavf/dump: Remove superfluous cast. [01:35:13 CEST] <gh0st__> atomnuker: durandal_1707: Hm, I thought in writing any serious codec math is in first place(most likely linear algebra(transformations and etc.)) for analysis, design, etc. [01:36:07 CEST] <durandal_1707> gh0st__: it is for deep understanding [01:36:12 CEST] <TD-Linux> BBB, yes [01:36:31 CEST] <TD-Linux> see aom_cdf_adapt_q15 for the per symbol [01:36:50 CEST] <TD-Linux> we don't have a SIMD implementation for that but you should be able to make something nice [01:37:52 CEST] <durandal_1707> on CPU it takes ages to encode video with those modern codecs [01:38:57 CEST] <durandal_1707> gh0st__: start with lossless intra only and than upgrade with more stuff [01:41:21 CEST] <BBB> TD-Linux: hehe, dont worry, I like figuring simd things out myself ;) [01:42:54 CEST] <durandal_1707> modern codecs should be simdable a lot and also use all cores power [01:50:48 CEST] <gh0st__> durandal_1707: I agree, because that's about where the progress seems to gravitate to: more cores, bigger SIMD registers. [02:29:02 CEST] <cone-927> ffmpeg 03James Almer 07master:95a6de5674ab: avcodec/snowenc: fix setting motion_est option [03:18:28 CEST] <atomnuker> kierank: its no wonder all of france goes on holiday to the riviera, have you seen tgv prices? [03:18:41 CEST] <atomnuker> 150 euros for a return trip from paris to nice [03:18:52 CEST] <atomnuker> 175 in total if you make one of the trips first class [03:19:33 CEST] <atomnuker> this is obscene, eurostar trains aren't that cheap [03:22:44 CEST] <atomnuker> eurostar for today and return in 5 days is 250 pounds [03:23:50 CEST] <atomnuker> granted, the pound isn't very strong compared to the euro (barely 1.08 atm) but still [03:25:17 CEST] <atomnuker> goes to show the value of state ownership [04:32:24 CEST] <peloverde> Where is late arriving out of band extradata supposed to be forwarded to the codec with the codecpar API? [04:33:17 CEST] <atomnuker> peloverde: btw feel free to push the aac 960 patch, you're still the maintainer of the code [04:33:22 CEST] <atomnuker> just put me as an author too [04:33:49 CEST] <atomnuker> I wrote some code, gave it to durandal_1707, he wrote some code and then gave it to you :) [04:38:26 CEST] <peloverde> I pushed both patches with the author update [04:39:40 CEST] <atomnuker> huh, I guess I didn't pay attention then [04:42:45 CEST] <jamrial_> peloverde: as packet side data type "new extradata" i think [04:48:14 CEST] <rcombs> ^ this [04:51:01 CEST] <peloverde> jamrial_: That happens for subsequent extradata, but the first extradata gets written straight to codecpar (at least for FLV) [04:52:15 CEST] <jamrial_> you said late arriving, which means long after the header is read, right? so for that you just append it as side data in the packet you send to the decoder [04:53:17 CEST] <peloverde> That's not what this demuxer is doing, maybe that's what ti should be doing? In this case the extradata occurs during the find_stream_info window [04:56:32 CEST] <peloverde> In this particular case the extradata occurs directly after the 1st frame [05:04:03 CEST] <jamrial_> mmh, flvdec.c is probably doing things wrong. codecpar->extradata is supposed to be filled during read_header(), and anything that shows up in a packet must be propagated as side data [05:05:47 CEST] <jamrial_> is this h264 in flv? h264dec seems to work fine if extradata is not set during init(). it will use any extradata sent as side data afterwards [05:07:47 CEST] <peloverde> aac in flv [05:08:10 CEST] <peloverde> some ticket about a regression [05:08:22 CEST] <peloverde> gotta go, i'll finish this later [05:11:33 CEST] <jamrial_> peloverde: apparently should also be good [05:11:35 CEST] <jamrial_> flvdec needs to be updated to just send everything as side data if it can't be set during read_header() [05:52:54 CEST] <stevenliu> Not only flvdec hls.c need also when DISCONTINUITY [06:52:24 CEST] <jamrial_> peloverde: actually, the code that reads new extradata in aacdec is disabled for some reason, so it's never looking at it [06:54:08 CEST] <jamrial_> after enabling it and making flvdec send every extradata as side data the file decodes (with some errors at the beginning, maybe a first frame before extradata is propagated) [08:42:46 CEST] <nevcairiel> maybe some smart code would be useful that actually updates codecpar if during find_stream_info there is a new extradata message and extradata is otherwise empty [11:05:26 CEST] <Compn> hmm [11:05:29 CEST] <Compn> alibaba security team [11:05:31 CEST] <Compn> thats neat [11:05:41 CEST] <Compn> gotta secure incoming video [11:06:12 CEST] <Compn> since they are fixing dos, i wonder if that means google video has a better way to abort DoS fuzzes [11:06:44 CEST] <nevcairiel> if such a dos affects you, then your whole setup aint very good [11:06:54 CEST] <Compn> right [11:07:14 CEST] <nevcairiel> sandbox the thing and just kill it if it doesnt finish [11:07:37 CEST] Action: Compn should buy some BABA stock [11:07:50 CEST] <Compn> amazon needs to get video in its products page [11:13:16 CEST] <Compn> still its nice that alibaba sends patches [11:13:22 CEST] <Compn> :) [11:59:32 CEST] <jkqxz> wm4: V4L2 hwcontext is made somewhat tricky by the userptr stuff. The ability to point to random places in host-virtual-memory is probably wanted (though I do wonder whether drivers will just copy it anyway), and doesn't fit in how it currently works. [12:00:01 CEST] <jkqxz> If it was only V4L2_MEMORY_DMABUF (i.e. DRM fds) then it would be easy. [12:00:34 CEST] <wm4> *shrug* [12:05:26 CEST] <jkqxz> I think it's still possible with slightly more mapping than perhaps hoped. E.g. an encoder taking an mmap context as input has to make a userptr context and map to it rather than being able to use the mmap one directly. [12:06:14 CEST] <jkqxz> But I'm not sure I want to argue for it. [12:06:28 CEST] <jkqxz> Do we know if there is any other hardware this works on beyond the qualcomm things? [12:06:51 CEST] <rcombs> people keep telling me it's the future, but I dunno who else is working on implementing it either [12:08:44 CEST] <jkqxz> Maybe I can just buy one of the dragonboards. [12:08:53 CEST] <wbs> jkqxz: samsung has got v4l2 m2m drivers for some of their exynos chips [12:09:02 CEST] <wbs> but they've got tiled pixelformats and other crazy things [12:09:20 CEST] <wbs> (the same patchset was proposed a few years ago, including adding libavutil pixformats for the samsung tiled format) [12:10:36 CEST] <jkqxz> Tiling is fine in hwcontext land, because it hides that sort of thing unless you really want to map it. (Another argument for it...) [12:20:00 CEST] <jkqxz> Anyone have an Odroid XU4? That seems to be the obvious way to get a Exynos. [12:20:40 CEST] <jkqxz> The Qualcomm stuff isn't obviously sold in this country at all. [12:22:34 CEST] <wbs> jkqxz: I've got one of the dragonboards, and I ordered it from arrow. it was a bit of a hassle back then (it wasn't really ready for shipping when I ordered it), but hopefully it goes smoother now [12:28:56 CEST] <RiCON> BtbN: can you confirm that nppi.lib is missing from cuda sdk 9 RC? [13:08:03 CEST] <BtbN> RiCON, it very much looks like it so far [13:08:41 CEST] <RiCON> no mention of it being deprecated/obsolete in the release notes [13:09:00 CEST] <BtbN> it's just renamed/split or something [13:09:05 CEST] <BtbN> there's nppif and nppif now [13:09:11 CEST] <BtbN> nppig [16:30:18 CEST] <wm4> kierank: lol that MXF thing [16:34:21 CEST] <kierank> wm4: it's argument you won't win [16:35:16 CEST] <kierank> it's an argument I had years ago about ts, I was called names and then I went and did my own thing [16:35:16 CEST] <rcombs> what, 6518? [16:44:01 CEST] <thardin> oh yeah, mxf. I tried to suggest switching to libmxf for sanity [16:45:34 CEST] <thardin> no dice [16:46:03 CEST] <thardin> or that other library. bmx or whatever [17:00:36 CEST] <JEEB> sounds like a sound alternative since those projects most likely care about those formata [17:03:40 CEST] <cone-851> ffmpeg 03Nicolas George 07master:6bde475cf2f9: lavfi/f_streamselect: convert to framesync2. [17:03:41 CEST] <cone-851> ffmpeg 03Nicolas George 07master:0ae8df4109da: lavfi/framesync2: add dualinput helper functions. [17:03:42 CEST] <cone-851> ffmpeg 03Nicolas George 07master:19804024d5b2: lavfi/vf_overlay: move to framesync2. [17:03:43 CEST] <cone-851> ffmpeg 03Nicolas George 07master:f8d7b5febba0: lavfi: add a preinit callback to filters. [17:03:44 CEST] <cone-851> ffmpeg 03Nicolas George 07master:dfa3aaa22a2b: lavfi: search options on child objects. [17:03:45 CEST] <cone-851> ffmpeg 03Nicolas George 07master:05a23b256584: lavfi/framesync2: add common options. [17:03:45 CEST] <cone-851> ffmpeg 03Nicolas George 07master:878fd0545a93: lavfi/vf_overlay: use framesync2 options. [17:03:47 CEST] <cone-851> ffmpeg 03Nicolas George 07master:c1d8d33a51e3: lavfi/vf_blend: convert to framesync2. [17:03:48 CEST] <cone-851> ffmpeg 03Nicolas George 07master:a8ab52fae728: lavfi/vf_libvmaf: convert to framesync2. [17:03:49 CEST] <cone-851> ffmpeg 03Nicolas George 07master:eacb3ec96103: lavfi/vf_lut3d: convert to framesync2. [17:03:50 CEST] <cone-851> ffmpeg 03Nicolas George 07master:23000c3de594: lavfi/vf_paletteuse: convert to framesync2. [17:03:51 CEST] <cone-851> ffmpeg 03Nicolas George 07master:3bd11df45986: lavfi/vf_psnr: convert to framesync2. [17:03:52 CEST] <cone-851> ffmpeg 03Nicolas George 07master:ef2176473d3d: vf_ssim: convert to framesync2. [17:03:53 CEST] <cone-851> ffmpeg 03Nicolas George 07master:607900c905c4: lavfi: remove dualinput. [17:03:54 CEST] <cone-851> ffmpeg 03Nicolas George 07master:844bc0d89e1d: doc/filters: document framesync options. [17:03:55 CEST] <cone-851> ffmpeg 03Nicolas George 07master:7302d5e32597: lavfi: bump minor version after change in options. [17:04:07 CEST] <durandal_1707> no commrnts for my despill filter? [17:05:28 CEST] <BtbN> I just wonder if it'd make sense to combine it with the other keying filters [17:05:54 CEST] <BtbN> but I guess it can be useful on its own. Just seems slightly less efficient, as it means iterating all pixels again [17:58:37 CEST] <tdjones> atomnuker: Have you had a chance to look at my patches? Are there any changes that need to be made in order to merge? [19:06:30 CEST] <peloverde> nevcairiel: jamrial If the stream uses a codec that supports extract_extradata then find_stream_info side data is promoted to primary extradata if none is present. It seems like this behavior should be extended to non extract_extradata codecs. [19:09:34 CEST] <jamrial> peloverde: yeah, tried that and it seems to work [19:10:41 CEST] <jamrial> peloverde: something like https://pastebin.com/euRdmErk [19:17:40 CEST] <peloverde> I think that approach means we will eat a non-find-stream-info late extradata [19:18:36 CEST] <jamrial> what do you mean? that's inside find_stream_info [19:18:59 CEST] <peloverde> yes, but the demuxer is still setting the first extradata straight to codecpar [19:19:20 CEST] <peloverde> the demuxer should always create a side data for non header extradata was my understanding from last night [19:19:40 CEST] <peloverde> then the side data extradata should be promoted, not the codecpar extradata [19:23:17 CEST] <jamrial> flvdec seems to set AVFMTCTX_NOHEADER, which means no header is present and streams are added dinamically as probe packets are read. that i assume, would include the first extradata into codecpar [19:25:07 CEST] <jamrial> the extradata doesn't show up until like the fifth packet it seems, at which point find_stream_info already copied stuff into st->internal->avctx from codecpar. new stuff added to codecpar after that point even by AVFMTCTX_NOHEADER demuxers is apparently ignored [19:25:19 CEST] <peloverde> So what is supposed to happen for late first extradata past the end of find_stream_info? Is it a case of if you've mad it this far you probably are okay without it? [19:26:04 CEST] <jamrial> if it's outside of the find_stream_info probe window then the stream will not be readable and it will ask you to increase probe size, i guess [19:26:18 CEST] <jamrial> or just fail like it's doing right now [19:27:11 CEST] <peloverde> There are some codecs that take optional extradata. [19:27:38 CEST] <jamrial> yeah, aac is supposedly one of them [19:27:59 CEST] <peloverde> If the decoder inits successfully with the default config, then you get new extradata later it kind of seems like it should be forwarded and not eaten [19:28:02 CEST] <jamrial> but the code to read extradata in packet side data is disabled for some reason [19:29:47 CEST] <peloverde> Is there any documentation of the expectations of when demuxers can and can't fill codecpar? [19:30:13 CEST] <jamrial> avcodec.h, if at all [19:30:42 CEST] <wm4> for some self-contained codecs you can decode with basically an empty codecpar [19:30:43 CEST] <jamrial> but afaics, codecpar is filled in read_header() only, unless AVFMTCTX_NOHEADER is set [19:31:15 CEST] <wm4> find_stream_info is more a separate feature that enables ffprobe and some bad software to know redundant codec parameters before decoding [19:31:45 CEST] <jamrial> within packets, if you need new extradata you use packet side data type "new extrada", and if you need to change stream parameters you use packet side data type "Data param change" [19:31:59 CEST] <jamrial> but you don't modify codecpar [19:32:08 CEST] <jamrial> since that will not be propagated to the decoder [19:32:18 CEST] <peloverde> Right now I only care about AVFMTCTX_NOHEADER formats [19:32:35 CEST] <jamrial> in that case, you should probably be able to change codecpar fields [19:32:40 CEST] <jamrial> flvdec seems to do it after all [19:32:57 CEST] <jamrial> but find_stream_info might not be handling things right [19:33:47 CEST] <peloverde> jamrial: "you should probably be able to change codecpar fields" Up until what point? The end of the stream [19:33:58 CEST] <peloverde> I feel like we're going around in circles here [19:34:49 CEST] <nevcairiel> you cant change codecpar after it has been created and returned to the caller once [19:35:06 CEST] <nevcairiel> there is a few exceptions to that, but lets stick with that =p [19:35:17 CEST] <peloverde> nevcairiel: okay, that makes sense to me [19:37:28 CEST] <jamrial> peloverde: that's why i said find_stream_info might not be handling things right. it copies the contents of codecpar to the internal avctx struct in AVStream once then never again, even for AVFMTCTX_NOHEADER formats that are supposed to dig deeper for new streams and stream info [19:38:16 CEST] <nevcairiel> there is a flag things can set if they update the codecpar for whatever reason [19:38:20 CEST] <nevcairiel> mpegts uses it [19:38:31 CEST] <nevcairiel> but most things s hould just create the stream only when they know the info [19:42:48 CEST] <jamrial> nevcairiel: need_context_update? [19:46:27 CEST] <peloverde> hah, it works [19:49:04 CEST] <jamrial> what does? [19:49:18 CEST] <peloverde> Setting need_context_update [19:51:11 CEST] <jamrial> nice. pastebin? [19:52:08 CEST] <peloverde> https://pastebin.com/yJz2FyPw [19:53:44 CEST] <jamrial> this would also affect h264 streams. do we have any such sample? [19:55:16 CEST] <peloverde> It seems like it should. The use of IDR frames make things a little weirder. [19:55:34 CEST] <peloverde> You probably could create a synthetic stream by moving the extradata after the first frame. [19:56:26 CEST] <jamrial> mmh, the file is reported as mono with this approach [19:56:49 CEST] <peloverde> It is mono [19:57:00 CEST] <peloverde> Or does it use PS? [19:58:04 CEST] <peloverde> you're right, it has stereo [20:27:24 CEST] <peloverde> it looks like AV_CODEC_CAP_CHANNEL_CONF uses codec_info_nb_frames which doesn't get reset when the context update occurs [20:50:26 CEST] <peloverde> jamrial: I sent patches for both issues to the list [21:18:38 CEST] <cone-548> ffmpeg 03Michael Niedermayer 07master:429f3266c14a: avformat/mxfenc: Check that the video codec in D-10 is MPEG-2 [21:18:38 CEST] <cone-548> ffmpeg 03Michael Niedermayer 07master:6def8b8d924a: avcodec/h264idct_template: Fix integer overflow in ff_h264_idct8_add() [21:18:38 CEST] <cone-548> ffmpeg 03Michael Niedermayer 07master:2a83866c9f95: avcodec/hevc_ps: Fix undefined shift in pcm code [21:18:38 CEST] <cone-548> ffmpeg 03Michael Niedermayer 07master:732f97645615: avcodec/snowdec: Fix integer overflow in decode_subband_slice_buffered() [00:00:00 CEST] --- Wed Aug 30 2017

1 0

ffmpeg.log.20170829
by burek 30 Aug '17

30 Aug '17

[01:05:18 CEST] <guides> I got a question regarding ffmpeg and streaming to youtube, currently i'm able to stream a .png and a .mp3 file, but after the .mp3 file is done playing it's done streaming (obviously). Is there a parameter i'm missing to get it to loop forever? i janked together this combination of parameters to get this working, but having trouble finding a way to contiously loop the song without it stopping the stream. command/console output - https: [03:23:21 CEST] <nicolas17> I want to stabilize and denoise a video [03:23:26 CEST] <nicolas17> should I first denoise and then stabilize? [03:23:55 CEST] <nicolas17> and if so, should I use the denoise filter during both vidstabdetect and vidstabtransform steps? [03:29:46 CEST] <Cracki_> yes, first denoise [03:29:56 CEST] <Cracki_> noise is relative to the chip, not the video [03:30:45 CEST] <Cracki_> not sure how ffmpeg's vidstab works... it might be robust to noise [03:35:17 CEST] <stimple> oh ty, didn't know we had stabilization [03:35:59 CEST] <nicolas17> I have a script using MLT's videostab2 [03:36:11 CEST] <nicolas17> I'm glad to see ffmpeg supports videostab now [03:44:34 CEST] <nicolas17> I'm running my old script with melt now [03:44:40 CEST] <nicolas17> videostab is slow as hell on 1080p [03:53:42 CEST] <Cracki_> adobe premiere's stabilization isn't terribly fast either [03:54:16 CEST] <nicolas17> oh I know, this is *inherently* slow [03:54:24 CEST] <Cracki_> there are papers for decent algorithms that can run quite fast [03:54:46 CEST] <Cracki_> some are smarter about crunching numbers. [03:54:51 CEST] <Cracki_> some use the GPU [03:55:37 CEST] <Cracki_> I've seen realtime digital deshaking in handheld video cameras 20 years ago [03:56:01 CEST] <Cracki_> i.e. it deshook what it saw, even if the cam was stationary [03:56:07 CEST] <atomnuker> vf_deshake can use opencl [03:56:35 CEST] <nicolas17> I have integrated intel GPU on a laptop, I don't think OpenCL will make miracles [03:58:16 CEST] <Cracki_> don't discount it [03:58:32 CEST] <Cracki_> especially integrated GPUs have the advantage of direct access to main memory [03:59:14 CEST] <Cracki_> and compared to the CPU part, they easily have 10x the crunch for single precision [03:59:41 CEST] <nicolas17> model name : Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz [03:59:43 CEST] <nicolas17> OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile [04:00:45 CEST] <Cracki_> wikipedia says 332.8 gflops for the intel hd 4000 [04:01:19 CEST] <Cracki_> anyway, depending on algorithm, deshaking could be quite fast. [04:01:56 CEST] <Cracki_> I'd always go with pyramid schemes and optical flow-like computation [04:02:27 CEST] <wutsnek> hey peeps i have a question [04:02:46 CEST] <Cracki_> snek wut :P [04:03:10 CEST] <wutsnek> im using ffmpeg with an audio stream but ends up crashing after 20~ seconds [04:03:15 CEST] <wutsnek> [tls @ 0x242f9c0] Error in the pull function. [matroska,webm @ 0x242d340] Read error [04:03:20 CEST] <wutsnek> with this error [04:04:28 CEST] <Cracki_> update ffmpeg? [04:06:03 CEST] <nicolas17> oh, while I wasn't looking MLT finished running the videostab analysis [04:06:24 CEST] <nicolas17> 7642 1080p frames [04:21:09 CEST] <Cracki_> watching a tea pot boil [04:29:34 CEST] <wutsnek> it should be the latest versionhm why is the latest version hosted by ubuntu 2.8.11 [04:29:50 CEST] <nicolas17> what version of ubuntu? [04:29:50 CEST] <wutsnek> oops ignore the first part [04:30:19 CEST] <wutsnek> 16.03 [04:30:22 CEST] <wutsnek> 4 [04:30:22 CEST] <wutsnek> * [04:31:05 CEST] <nicolas17> then you're going to get a version that was somewhat latest back in April 2016 [04:32:05 CEST] <nicolas17> Cracki_: [04:32:08 CEST] <nicolas17> oops [04:32:14 CEST] <nicolas17> so what denoiser do you recommend? [04:32:37 CEST] <Cracki_> whatever looks good :P [04:32:49 CEST] <Cracki_> depends on the kind of "noise" [04:33:06 CEST] <furq> try them all out on some samples i guess [04:33:12 CEST] <nicolas17> iPhone camera on somewhat low light; I don't mind waiting for processing, since I'm going to spend so much CPU time on videostab anyway [04:33:15 CEST] <furq> hqdn3d is a good general-purpose one which is quite fast [04:33:17 CEST] <Cracki_> if the video is compressed to smudge, nothing can fix that [04:33:20 CEST] <furq> nlmeans is also good but slow [04:33:27 CEST] <furq> unless you use the opencl one in vapoursynth [04:33:58 CEST] <furq> but yeah ffmpeg has tons of them to test out [04:33:59 CEST] <Cracki_> be aware that the heavier the denoise, the more likely it is that the video is warped by the denoising [04:34:40 CEST] <furq> yeah you can sharpen it afterwards but obviously that's fraught with danger [04:35:00 CEST] <nicolas17> furq: apparently I need unsharp after videostab anyway [04:37:55 CEST] <furq> it's still generally better to denoise as little as you can [04:41:10 CEST] <nicolas17> furq: http://nicolas17.s3.amazonaws.com/noise-crop-640x480.mp4 [04:41:28 CEST] <nicolas17> I guess some "light" denoising will be enough [04:42:12 CEST] <furq> yeah that's not that bad [04:42:30 CEST] <furq> hqdn3d should do a perfectly good job with that [04:57:23 CEST] <Cracki> that calls for a temporal denoise [04:57:44 CEST] <Cracki> not high-frequency enough for spatial denoise to make sense [05:03:30 CEST] <furq> right [05:10:13 CEST] <Cracki> never worked with hqdn3d, sounds like the right tool though :P [05:11:58 CEST] <nicolas17> [AVFilterGraph @ 0x557d8d435460] No such filter: 'vidstabdetect' [05:12:00 CEST] Action: nicolas17 cries [05:12:57 CEST] <Cracki> now you'll learn how the sausage is made [05:13:34 CEST] <nicolas17> Cracki: I wrote my own transcoder with libavcodec/libavformat APIs, I already know too much about the sausage [05:13:40 CEST] <Cracki> :D [05:16:44 CEST] <nicolas17> the problem is vidstab is not packaged in debian [05:16:48 CEST] <nicolas17> where do I get that? [05:16:59 CEST] <nicolas17> https://github.com/georgmartius/vid.stab is it this one? [05:18:36 CEST] <furq> nicolas17: https://www.johnvansickle.com/ffmpeg/ [05:18:40 CEST] <furq> there are static builds with vidstab there [05:41:57 CEST] <nicolas17> built vidstab, now building ffmpeg [05:46:25 CEST] <mozzarella> guys help [05:47:22 CEST] <mozzarella> I've got a gigantic (file size) video that is just the raw stream from my cctv camera, how do I shrink it down without losing quality [05:49:01 CEST] <stimple> you don't [05:49:20 CEST] <stimple> well you can use huffyuv [05:50:12 CEST] <c3r1c3-Win> mozzarella: You could try x264 using CRF instead of bitrate as the compressor's main metric. [05:50:26 CEST] <nicolas17> stimple: even that will technically lose quality if the source is RGB :P [05:50:42 CEST] <stimple> ok yes [05:50:58 CEST] <furq> huffyuv does rgg [05:51:00 CEST] <furq> rgb [05:51:04 CEST] <c3r1c3-Win> But any form of anything approaching lossless will take up a ton of space, so if you scrafice just a touch of quality you can get the files to much smaller. [05:51:21 CEST] <c3r1c3-Win> *to a MUCH smaller size. [05:51:28 CEST] <redrabbit> i beleive he is not looking for lossless [05:51:30 CEST] <furq> if it's a raw stream from cctv then it's probably already mjpeg or h264 or something [05:51:47 CEST] <furq> i doubt a cctv camera is putting out raw yuv [05:51:50 CEST] <redrabbit> he wants little perceived quality difference [05:51:59 CEST] <mozzarella> Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709), 1280x720 [SAR 1:1 DAR 16:9], 2046 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 60 tbc (default) [05:52:05 CEST] <furq> right [05:52:10 CEST] <Cracki> 20 Mbit/s? [05:52:11 CEST] <furq> also that's not particularly big [05:52:12 CEST] <Cracki> that's not bad [05:52:16 CEST] <furq> that's 2mbps [05:52:17 CEST] <Cracki> 2.0* [05:52:26 CEST] <Cracki> how "big" is that anyway [05:52:37 CEST] <nicolas17> 2mbps, I don't think you can go much lower than that without noticeably losing quality... unless there's very very little movement ^^ [05:52:39 CEST] <Cracki> you could drop framerate, set higher keyframe intervals, ... [05:52:40 CEST] <redrabbit> its going to be hard to compress further without botching it [05:52:50 CEST] <furq> there will probably be very little movement and it's just a garbage hardware encoder [05:52:56 CEST] <furq> but there's also a good chance it's noisy as well [05:52:58 CEST] <mozzarella> 9.7 GB for a 10.5 hours video [05:52:58 CEST] <furq> hell [05:53:03 CEST] <Cracki> if it's a security camera pointed at a motionless scene, you can compress it some more [05:53:08 CEST] <furq> yeah that's not gigantic at all [05:53:35 CEST] <Cracki> so thats 8 TB/year [05:53:48 CEST] <Cracki> if you mean to retend that long [05:53:52 CEST] <nicolas17> I ran my old videostab script and it gave me 1GB for 4 minutes [05:54:01 CEST] <nicolas17> turns out it was doing huffyuv, I forgot about that :P [05:54:03 CEST] <mozzarella> I've get videos that are similar in length and they are ~1.5 GB, not sure how I did it [05:54:16 CEST] <mozzarella> got* [05:54:21 CEST] <Cracki> play with keyframe interval [05:54:27 CEST] <nicolas17> [00:50] <c3r1c3-Win> mozzarella: You could try x264 using CRF instead of bitrate as the compressor's main metric. [05:54:30 CEST] <nicolas17> that's the best place to start [05:54:32 CEST] <furq> yes, that [05:54:36 CEST] <Cracki> if nothing moves (see denoising), compression can work on the real content [05:54:40 CEST] <furq> just encode with x264 defaults and see what happens [05:54:50 CEST] <furq> -i in.mp4 out.mp4 [05:54:50 CEST] <Cracki> yeah crf, i second that [05:55:00 CEST] <mozzarella> furq: that would work? [05:55:03 CEST] <furq> shrug [05:55:05 CEST] <furq> it depends on the source [05:55:05 CEST] <Cracki> defaults are pointless. default bitrate is 200 kbit/s [05:55:08 CEST] <furq> no it isn't [05:55:14 CEST] <furq> the x264 default is -crf 23 [05:55:14 CEST] <Cracki> oh right, x264 not ffmpeg [05:55:18 CEST] <furq> with ffmpeg [05:55:38 CEST] <furq> the global default is 200kbps but codecs can override that individually [05:55:49 CEST] <furq> the x264 defaults are pretty sensible [05:55:58 CEST] <furq> preset medium, crf 23 [05:59:43 CEST] <mozzarella> how long is it going to take? [06:00:57 CEST] <mozzarella> why do I keep getting "Past duration 0.something too large" [06:02:01 CEST] <nicolas17> the status bar should show 'fps' [06:02:08 CEST] <nicolas17> that's how many frames it's encoding per second [06:02:17 CEST] <mozzarella> there's no status bar [06:02:33 CEST] <nicolas17> I get a line like "frame= 300 fps= 56 q=-0.0 Lsize= 84886kB time=00:00:10.01 bitrate=69462.4kbits/s speed=1.88x" that updates every second [06:02:52 CEST] <dystopia_> yeah thats in the command window [06:03:03 CEST] <dystopia_> it would be nice if it was in the status bar though [06:03:55 CEST] <mozzarella> there's no ETA [06:03:59 CEST] <mozzarella> or % [06:04:09 CEST] <nicolas17> you can calculate it from "speed" [06:04:17 CEST] <dystopia_> you can do the eta maths yourself [06:04:19 CEST] <dystopia_> yeah [06:04:21 CEST] <nicolas17> if it says 1x it means a 10-hour video will take 10 hours to encode [06:04:29 CEST] <mozzarella> oh jesus [06:04:31 CEST] <Cracki> ? [06:04:34 CEST] <nicolas17> so what does it say? [06:04:36 CEST] <Cracki> 1x means 1x speed [06:04:41 CEST] <mozzarella> 3.11x [06:04:42 CEST] <Cracki> post the line? [06:04:52 CEST] <dystopia_> then devide duration by 3.1x [06:04:57 CEST] <Cracki> so 3 hours [06:05:06 CEST] <nicolas17> you should encode like [06:05:06 CEST] <mozzarella> still seems excessive to me [06:05:07 CEST] <Cracki> 3x isn't so bad. what resolution? [06:05:08 CEST] <nicolas17> a few minutes of video [06:05:13 CEST] <nicolas17> to see what the quality is like [06:05:14 CEST] <furq> lol 69mbps [06:05:23 CEST] <furq> is the source noisy or blocky by any chance [06:05:27 CEST] <Cracki> if medium is too slow for you, go try fast/faster/veryfast [06:05:36 CEST] <nicolas17> furq: my 69mbps is huffyuv :P [06:05:42 CEST] <furq> oh right [06:05:42 CEST] <Cracki> you can go higher with the crf too, but check the results [06:05:43 CEST] <furq> duh [06:05:48 CEST] <furq> well yeah [06:05:54 CEST] <furq> mozzarella: make sure it's actually coming in lower than 2mbit [06:05:56 CEST] <dystopia_> 3.1x is fast heh [06:05:57 CEST] <furq> otherwise you're wasting your time [06:05:58 CEST] <Cracki> ah, 69 Mbit/s would have been 4k footage :P [06:06:08 CEST] <Cracki> (for typical 264 bitrates) [06:06:13 CEST] <nicolas17> what am I supposed to see with vidstabdetect=show=1? [06:06:22 CEST] <furq> nah you'll get that with something like noisesrc [06:06:23 CEST] <mozzarella> frame=21167 fps= 93 q=-1.0 Lsize= 20443kB time=00:11:46.38 bitrate= 237.1kbits/s dup=10 drop=7 speed=3.11x [06:06:25 CEST] <mozzarella> video:17648kB audio:2411kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.913213% [06:06:30 CEST] <Cracki> much better [06:06:31 CEST] <furq> yeah there you go [06:06:44 CEST] <furq> check it actually still looks good obv [06:07:01 CEST] <furq> i wouldn't use any preset above faster if you actually want it to compress well [06:07:12 CEST] <Cracki> ^ [06:07:21 CEST] <mozzarella> I didn't change a thing, that's the output I got initially [06:07:39 CEST] <furq> right, that's -preset medium [06:07:44 CEST] <furq> (the default) [06:07:49 CEST] <Cracki> yes initially it spends bits on a keyframe, and maybe the video moves a bit still. [06:08:06 CEST] <nicolas17> ohhhh [06:08:07 CEST] <Cracki> as soon as the video quiets down, bitrate goes down too. [06:08:14 CEST] <nicolas17> I have to produce a video file with vidstabdetect [06:08:17 CEST] <Cracki> it'll spend bits on keyframes regularly, I hope [06:08:18 CEST] <nicolas17> that's where the debugging info is [06:08:18 CEST] <furq> fwiw if it's a security camera you can try messing with mpdecimate [06:08:27 CEST] <furq> that'll drop sequential identical frames [06:08:30 CEST] <furq> !filter mpdecimate [06:08:30 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#mpdecimate [06:08:35 CEST] <Cracki> nice [06:08:51 CEST] <furq> not sure if the detection is slower than encoding those frames [06:08:56 CEST] <furq> but it'll definitely make the video smaller [06:09:22 CEST] <Cracki> mpdecimate drops the whole frame. h264 would compress the differences only in any case. [06:09:42 CEST] <furq> right, but you'll get fewer IDR frames [06:09:51 CEST] <Cracki> true [06:09:57 CEST] <furq> possibly much fewer [06:10:19 CEST] <Cracki> idr = intra/key? [06:10:26 CEST] <furq> intra decoder refresh [06:10:28 CEST] <furq> (yes) [06:10:29 CEST] <Cracki> ic [06:10:46 CEST] <furq> or instant decoder refresh, rather [06:10:58 CEST] <Cracki> subtle differences in meaning, perhaps [06:11:11 CEST] <furq> that's what you'd think of as a keyframe [06:11:13 CEST] <Cracki> "An IDR frame is a special kind of I frame used in MPEG-4 AVC encoding. Frames following an IDR frame may not refer back to frames preceding the IDR frame. IDR frames can be used to create AVC streams which are more easily edited " [06:11:25 CEST] <mozzarella> you guys make me realize I know close to nothing about video encoding [06:11:41 CEST] <Cracki> I can just google quicker than the average bear [06:11:48 CEST] <Cracki> s/google/duckduckgo/ [06:12:25 CEST] <Cracki> btw, alternative video platforms: vimeo (traditional), bitchute and dtube.video (p2p tech) [06:12:25 CEST] <furq> idle in here for long enough and you too will be able to convincingly hold a conversation about video [06:12:45 CEST] <Cracki> if you zig, you gotta zag too [06:12:57 CEST] <dystopia_> lol [06:13:06 CEST] <Cracki> I hear the BBQ transform is the new hype [06:13:08 CEST] <dystopia_> i love this channel :O [06:13:34 CEST] <Cracki> the successor to yolo, yolo2, is even better for object recognition [06:13:58 CEST] <Cracki> ^ not joking [06:14:16 CEST] <mozzarella> for some reason -preset faster is even slower than medium [06:14:19 CEST] <nicolas17> what's that anime-oriented scaler? [06:14:42 CEST] <nicolas17> I don't remember the name [06:14:51 CEST] <dystopia_> there is -tune animation [06:14:55 CEST] <dystopia_> do you mean scaler? [06:15:01 CEST] <nicolas17> ah waifu2x [06:15:08 CEST] <nicolas17> dystopia_: while we're talking of silly names [06:16:13 CEST] <stimple> waifu2x is fast enough to do video? [06:17:12 CEST] <nicolas17> stimple: sure it can do video, not sure at what fps (or spf) :D [06:18:26 CEST] <stimple> these neural net scalers are pretty awesome [06:18:33 CEST] <Cracki> waifu2x is sensitive to noise... [06:18:57 CEST] <Cracki> be aware that neural net scalers introduce hallucinations depending on what they're trained on [06:19:03 CEST] <stimple> yes [06:19:15 CEST] <Cracki> the added information is not in the picture, but in the preconceptions it was trained on [06:19:17 CEST] Action: nicolas17 plays with vidstab parameters [06:19:24 CEST] <dystopia_> i thought rule 101 of video encoding was never upscale :O [06:19:40 CEST] <furq> nnedi is pretty good [06:19:45 CEST] <furq> mostly for deinterlacing though [06:19:57 CEST] <Cracki> rule 34 [06:20:05 CEST] <furq> obviously it is good at deinterlacing by being good at 2x upscaling, but why would you ever do the latter [06:20:16 CEST] <furq> unless you're making 4k blurays ofc [06:20:17 CEST] <Cracki> upscaling old shitty footage [06:20:46 CEST] <Cracki> anime are "easy" to upscale because lots of uniform-colored polygons [06:20:52 CEST] <Cracki> *areas [06:21:06 CEST] <Cracki> it only has to preserve edges well, not so much texture [06:21:39 CEST] <Cracki> https://raw.githubusercontent.com/nagadomi/waifu2x/master/images/slide.png [06:22:06 CEST] <dystopia_> :O [06:22:10 CEST] <Cracki> ya [06:22:11 CEST] <dystopia_> miku is my waifu [06:22:15 CEST] <dystopia_> you can't have her! [06:22:36 CEST] <Cracki> don't wanna. it's not a boy [06:22:40 CEST] <dystopia_> the scaling looks good though [06:22:42 CEST] <dystopia_> hehe [06:22:48 CEST] <Cracki> it does indeed. [06:23:07 CEST] <Cracki> and I'm sure it works fine for several iterations [06:30:30 CEST] <stimple> neural nets aren't going to get us -- yet [06:38:08 CEST] <c3r1c3-Win> Luka > all. [06:48:48 CEST] <dystopia_> luka luka nightfever [06:50:02 CEST] <c3r1c3-Win> So if Miku catches LukuLuka Nightfever, what does it turn into? [06:50:11 CEST] <c3r1c3-Win> MikuMiku Head cold. [06:55:11 CEST] <dystopia_> i think we might be weebs c3r1c3-Win [06:55:21 CEST] <c3r1c3-Win> LOL [06:55:45 CEST] <sgo11> hi, mp4 file will pick a frame from the file as the preview image (thumbnail). What is the logic? How can I let it to pick the frame that I want? thanks a lot. [06:55:56 CEST] <furq> that depends on your file manager [06:56:52 CEST] <sgo11> furq, I tried four different file managers and apps in two platforms (linux and android). All pick the same image. that is weird. I want to change that image. Is that possible? thanks. [06:56:57 CEST] <mozzarella> alright guys [06:57:08 CEST] <c3r1c3-Win> Correct me if I'm wrong, but I do seem to remember that your can set a thumbnail for MP4 files... but even if you can, it does depend on your file manager. [06:57:17 CEST] <mozzarella> how can I put a limit of 25% CPU usage, when encoding [06:57:21 CEST] <nicolas17> ugh [06:57:33 CEST] <mozzarella> I just don't want my fan to spin like crazy, I don't care how long it takes [06:57:46 CEST] <nicolas17> mozzarella: do you have multiple cores? [06:57:47 CEST] <c3r1c3-Win> I'm not saying FFMPEG supports (or doesn't support) such, but I remember reading in the file spec something to that effect. [06:57:52 CEST] <mozzarella> nicolas17: I do [06:58:03 CEST] <nicolas17> maybe ffmpeg is automatically using multiple threads to speed things up [06:58:08 CEST] <mozzarella> it is [06:58:13 CEST] <mozzarella> it's using my 4 cores [06:58:18 CEST] <dystopia_> you could slow it down with -re possibly [06:58:20 CEST] <mozzarella> so almost 400% [06:58:26 CEST] <dystopia_> if it's encoding faster than realtime as it is [06:58:35 CEST] <c3r1c3-Win> You should be able to tell ffmpeg to use fewer threads/cores. [06:58:37 CEST] <mozzarella> what's -re? [06:58:40 CEST] <nicolas17> so "-threads 1" will limit it [06:58:47 CEST] <dystopia_> encodes out put at input framerate [06:59:09 CEST] <dystopia_> so if a 25fps video was encoidng at 100fps or 4x, it would be limited to 25% [06:59:16 CEST] <nicolas17> urgh, vidstab's tripod mode was giving me great results [06:59:23 CEST] <nicolas17> but it gets very confused when brightness changes [06:59:24 CEST] <sgo11> For example, my pcmanfm-qt file manager in linux and ES File Manager App in android both are using the same thumbnail. I am satisfied if I can change the thumbnail of these two file managers. any suggestions? thanks. [06:59:25 CEST] <dystopia_> but if your encoding slower than output framerate, nothing will happen [06:59:34 CEST] <nicolas17> camera automatically changed the exposure when the projector turned on [06:59:49 CEST] <nicolas17> sgo11: aren't they using the first frame? [07:00:05 CEST] <sgo11> nicolas17, :) they are not. if they do, I will not ask here. [07:00:29 CEST] <mozzarella> still using 4 threads, lol [07:00:37 CEST] <mozzarella> wth [07:00:42 CEST] <nicolas17> mozzarella: with -threads 1? [07:00:57 CEST] <mozzarella> nicolas17: yeah [07:01:09 CEST] <mozzarella> do I need to put it in front of the file name or what? [07:01:19 CEST] <c3r1c3-Win> sgo11: https://superuser.com/questions/597945/set-mp4-thumbnail [07:01:53 CEST] <nicolas17> mozzarella: -filter_threads 1? [07:02:30 CEST] <mozzarella> still not working [07:02:39 CEST] <sgo11> c3r1c3-Win, I tried that. That won't work because the file managers I tried are not reading the cover tag. They pick a frame image. [07:03:01 CEST] <dystopia_> try the -re flag mozzarella it might help [07:03:15 CEST] <c3r1c3-Win> sgo11: If that's the case you really have no control over it. [07:03:27 CEST] <dystopia_> ffmpeg -re -i whatever.... [07:03:33 CEST] <nicolas17> maybe they are hardcoded to take the nth frame [07:03:45 CEST] <sgo11> c3r1c3-Win, All the apps I tried in android are not reading the cover tag. And All the apps are using the same frame image. that's why I want to know the logic and what the frame is. [07:04:14 CEST] <dystopia_> it's probably 1st i frame [07:04:40 CEST] <sgo11> nicolas17, if they are hardcoded, I am wondering what the logic is. Because all apps are using the same frame image as thumbnail. There must be a logic. [07:04:49 CEST] <mozzarella> alright, still using 150% CPU, though& [07:05:01 CEST] <c3r1c3-Win> Most of the time I see it's the 4-second frame (or 3rd i-frame) that's selected... or something like that. [07:05:11 CEST] <dystopia_> i wish my cpu could use 150% [07:05:18 CEST] <dystopia_> i would have 6hz [07:05:21 CEST] <c3r1c3-Win> sgo11: Best thing is to look at the source code. ;-) [07:05:23 CEST] <dystopia_> 6ghz [07:05:32 CEST] <nicolas17> dystopia_: multicore :P [07:05:38 CEST] <dystopia_> hehe [07:05:51 CEST] <sgo11> ok... let me see. [07:16:40 CEST] <mozzarella> guys [07:16:54 CEST] <mozzarella> can I pause/stop it and resume it in a few hours? [07:19:43 CEST] <nicolas17> on Linux, Ctrl-Z :P [07:19:49 CEST] <nicolas17> and the 'fg' command to resume [07:20:03 CEST] <mozzarella> other than that [07:20:48 CEST] <dystopia_> on windows use the pause key on the keyboard [07:20:58 CEST] <dystopia_> and return key to resume [07:21:57 CEST] <nicolas17> there is a *lot* of intermediate state in memory and there is no way to dump it to disk [07:26:41 CEST] <nicolas17> is vidstabtransform's interpolation parameter for pixel interpolation or camera path interpolation? [07:28:15 CEST] <Cracki> on windows, just select in the terminal. it'll fill up the output buffer and block the process. [07:40:32 CEST] <nicolas17> is there any filter to compensate brightness changes across time? [07:49:42 CEST] <Cracki> something that does auto gain/brightness/exposure? mebbeh... should be likely to exist [07:50:22 CEST] <Cracki> eq filter, says ddg [07:50:27 CEST] <nicolas17> I filmed a presentation, at one point I made the camera focus and adjust brightness for the projector image, which darkened the whole image [07:50:53 CEST] <nicolas17> when the image gets darkened a bit like that, vidstab gets absolutely confused and starts shaking the image around [07:51:23 CEST] <nicolas17> Cracki: eq seems to be to adjust the brightness by <expression> [07:51:29 CEST] <Cracki> ya, my mistake [07:51:46 CEST] <Cracki> if nothing else works, drop into python. pyav is getting soem development efforts [07:52:51 CEST] <Cracki> this maybe? https://video.stackexchange.com/questions/14603/what-is-the-ffmpeg-filter-e… [07:53:24 CEST] <Cracki> so pp=al [07:53:35 CEST] <Cracki> but that might need some thresholds [07:53:54 CEST] <Cracki> looks like it works on max/min only, not on some average brightness and range [07:54:29 CEST] <Cracki> what you'd need is an expression containing average brightness [07:54:53 CEST] <furq> !filter histeq [07:54:53 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#histeq [07:55:55 CEST] <Cracki> be aware histogram equalization can be nonlinear [07:59:17 CEST] <Cracki> ok I can't figure out what the hell that filter does. the colors are really weird [07:59:43 CEST] <nicolas17> Cracki: http://nicolas17.s3.amazonaws.com/vidstab-detect.mp4 [07:59:58 CEST] <Cracki> nice viz [08:00:21 CEST] <Cracki> if you have a video editing program, maybe look in there [08:00:46 CEST] <Cracki> i remember adobe premiere having a shitty autoexposure filter. maybe they rewrote or replaced that with something good. [08:01:39 CEST] <Cracki> if you can't find an autoexposure filter in ffmpeg, someone should maybe set that up as a GSoC task, or hit me up with handholding for filter programming [08:02:25 CEST] <nicolas17> sec, I'll show you what happens when I actually try to run vidstabtransform [08:02:28 CEST] <Cracki> the math is trivial to formulate for opencl, and the only issue would be working in a linear color space [08:02:55 CEST] <nicolas17> Cracki: http://nicolas17.s3.amazonaws.com/vidstab.mp4 [08:02:56 CEST] <Cracki> haha the vidstab gets confused by brightness changes, that's bad [08:03:10 CEST] <Cracki> that is bad [08:03:21 CEST] <Cracki> ok for the vidstabdetect, add a laplacian or sobel [08:03:34 CEST] <Cracki> this will remove absolute brightness and only give it edges/texture to work on [08:04:28 CEST] <Cracki> guys throw money at me, I'm good with computer vision, all that shit is easy to have, I just don't have any experience writing ffmpeg filters [08:07:33 CEST] <Cracki> right now I don't have the urge, but I was considering parallelizing the qtrle encoder too [08:12:57 CEST] <nicolas17> Cracki: I think pp=al is busted by the ceiling lights [08:13:05 CEST] <nicolas17> which stay at max brightness even as the whole image gets darker [08:13:09 CEST] <Cracki> yep, max/min, what I thought [08:13:39 CEST] <Cracki> if you anticipate more video work, see about doing it through a python step [08:14:37 CEST] <nicolas17> I'll try histeq [08:14:53 CEST] <Cracki> some step to get linear f32 or u16 from ffmpeg into python, then do stuff on that, then send it back. pyav uses the libraries directly, doesn't mess around with subprocesses like other wrappers [08:15:33 CEST] <nicolas17> I think that almost worked :O [08:15:42 CEST] <nicolas17> it looks ugly [08:15:49 CEST] <nicolas17> but it doesn't matter since it's only used for vidstabdetect [08:16:01 CEST] <nicolas17> now let's see the stabilized image [08:17:04 CEST] <nicolas17> there's some small high-frequency shaking hm [08:21:28 CEST] <Cracki> add smoothing [08:21:33 CEST] <Cracki> to the vidstab tracking [08:21:38 CEST] <Cracki> it should have options for that [08:22:09 CEST] <nicolas17> I'm using tripod mode, it's mutually exclusive with smoothing [08:22:11 CEST] <Cracki> ideally it should do subpixel-precise tracking (possible due to patch matching, not point matching), but no idea if it does [08:22:15 CEST] <Cracki> hm [09:01:28 CEST] <tadau> hi, i had an early dropout and can't play the resulting mp4 - any advice? [09:02:28 CEST] <tadau> err msg was sth like 'conversion failed'? [09:16:24 CEST] <Cracki> tadau, if that mp4 has no moov atom (process crashed), it can be hard/impossible to recover [09:16:50 CEST] <Cracki> what exactly do you mean [09:32:08 CEST] <tadau> Cracki: i encoded sth by: 'ffmpeg -i IN -c:v libx264 OUT.mp4' but unfortunately it stoped before time. When I try to play that OUT.mp4 I see an endless list of 'seek failed' errors. [09:32:39 CEST] <tadau> and before you ask - IN was a stream, so no chance to re-run that line [09:33:42 CEST] <tadau> what is this moov atom anyway - and why is it only calculated / made up in the end? [09:35:02 CEST] <Cracki> media containers contain tree structure [09:35:15 CEST] <Cracki> actual audio/video bitstreams, metadata, jump tables to keyframes, ... [09:35:38 CEST] <Cracki> the moov atom contains information about the streams, their codecs, durations, width height sample rate etc [09:36:01 CEST] <Cracki> for mp4s, the moov atom is usually written at the end, because you don't really know how large it'll be at the beginning [09:36:03 CEST] <tadau> but would'nt it be safer to keep these tables in small chunks all over the file? [09:36:09 CEST] <Cracki> if you do this a lot, look into segmented/fragmented mp4 [09:36:18 CEST] <Cracki> that does exactly this [09:36:41 CEST] <tadau> segmented/fragmented as an option to libx264? [09:36:42 CEST] <Cracki> other formats seem to be smarter about this. try this with mkv maybe [09:36:46 CEST] <Cracki> as an option to ffmpeg [09:36:53 CEST] <Cracki> it's a container option, not a codec option [09:37:01 CEST] <tadau> ok, will see the manual for that, tx [09:37:39 CEST] <tadau> and now for my broken file - what can be done, what could i try to recover or restore? [09:37:48 CEST] <Cracki> uh, what codecs were used? [09:38:29 CEST] <tadau> libx264 and libmp4lame [09:38:33 CEST] <tadau> libx264 and libmp3lame [09:38:41 CEST] <Cracki> you can try recreating the circumstances of the recording, and mess around with the moov atom, transplant it. it won't be perfect, but it *might*, if the bitstreams are interleaved exactly the same, give you access [09:38:57 CEST] <Cracki> possibly the bitstream packets/frames are contiguous in the mdat atom [09:39:07 CEST] <Cracki> if so, you could identify them, their length, and extract [09:39:16 CEST] <Cracki> this is the forensics approach [09:39:38 CEST] <tadau> wut? create a new file with the same length and cut of the end to paste it to the broken one?? [09:40:00 CEST] <Cracki> I've never had to do this for a multistream file, only for qtrle without audio (then the mdat contains the single qtrle video stream) [09:40:05 CEST] <Cracki> not quite [09:40:31 CEST] <Cracki> you'll have to maintain the proper tree structure, but maybe copying the moov atom contents is good enough [09:40:34 CEST] <Cracki> no guarantees though [09:40:47 CEST] <Cracki> especially for variable bitrate codecs, this is likely to fail [09:41:04 CEST] <Cracki> data is interleaved in the mdat atom. the interleaving is recorded outside, in the moov atom [09:41:34 CEST] <Cracki> some bitstream "frame" formats are unframed, so you can't reliably detect where they start and end [09:41:46 CEST] <Cracki> with knowledge of the codecs, you can eyeball it [09:42:06 CEST] <Cracki> the best assumption is that your file is junk [09:42:14 CEST] <tadau> so mp4 is keeping track of all those stuff in memory only? and only writes it down at the end? is that what you're telling me? [09:42:22 CEST] <Cracki> as long as it's still writing, yes [09:42:39 CEST] <tadau> wow - that *§$%§*"* [09:42:40 CEST] <Cracki> and it's not mp4, it's the application that does the muxing [09:42:44 CEST] <tadau> :( [09:42:54 CEST] <Cracki> that's why fragmented mp4 muxing option [09:43:07 CEST] <Cracki> fragmented/segmented, can't remember the term [09:43:14 CEST] <tadau> so you mean i would face the same probs with any other codec? [09:43:22 CEST] <Cracki> yes [09:43:25 CEST] <Cracki> the codecs are not at fault [09:43:43 CEST] <Cracki> it's a problem all container formats face. [09:43:56 CEST] <Cracki> some muxers periodically update a header... [09:44:05 CEST] <Cracki> even avi and mkv files can break. [09:44:16 CEST] <Cracki> the question is how recently did they write enough metadata [09:44:45 CEST] <tadau> Basic stream segmenter <- that one? [09:44:54 CEST] <Cracki> avi files are so old, most of the metadata is fixed length and iirc the interleaving is selfdelimited or something [09:44:58 CEST] <Cracki> no idea [09:45:13 CEST] <Cracki> lemme search [09:45:34 CEST] <Cracki> -movflags [09:45:37 CEST] <Cracki> that's the basic entry [09:45:42 CEST] <Cracki> https://ffmpeg.org/ffmpeg-formats.html#Options-8 [09:45:47 CEST] <Cracki> frag_keyframe perhaps [09:45:48 CEST] <tadau> The segmenter muxer outputs streams to a number of separate files of nearly fixed duration. Output filename pattern can be set in a fashion similar to image2. [09:45:57 CEST] <tadau> oh, tx [09:46:08 CEST] <Cracki> no need for separate files [09:46:25 CEST] <Cracki> -frag_duration maybe [09:46:29 CEST] <Cracki> depends on what you want [09:46:44 CEST] <tadau> yeah, didn't get it - thought it might create only virtual files inside a container [09:46:54 CEST] <Cracki> this will create one mp4/mov but it contains fragments (with moov atoms) at fixed intervals [09:47:02 CEST] <Cracki> it does. [09:47:10 CEST] <tadau> that sounds about right :) [09:47:31 CEST] <Cracki> ts are mpeg transport streams, they are a different beast [09:48:23 CEST] <Cracki> I'm not even sure if transport streams even contains an index. they don't interleave at all because the basic packet size is so small that it doesn't make sense [09:48:32 CEST] <Cracki> (meaning: a transport stream will never break) [09:48:49 CEST] <Cracki> so if you want to record, record to a transport stream or to a fragmented mov/mp4 [09:49:36 CEST] <tadau> but just out of curiousity and for any lazy folks that might be following us ;-) - could i've just said 'OUT.mkv' instead of 'OUT.mp4' and ffmpeg would have automagically saved me from this calamity? [09:51:05 CEST] <Cracki> not sure [09:52:06 CEST] <Cracki> mov and mkv are program formats. they're not meant to be faulttolerant. [09:52:34 CEST] <Cracki> "program"/"transport" is an MPEG-world distinction [09:53:02 CEST] <Cracki> program is the content and the content only. transport contains program + metadata for fault tolerance and other stuff, but doesn't contain "conveniences" such as seek tables. [09:53:28 CEST] <Cracki> "program" is logically what's presented to the viewer, i.e. all streams, their meanings, ... [09:54:14 CEST] <Cracki> HAH! just tried with frag_duration. it works as expected. [09:54:23 CEST] <Cracki> recorded ~14 secs at 5s intervals, playback shows me 10 secs [09:54:35 CEST] <Cracki> (because I killed the process. proper termination gives 14 secs) [09:54:39 CEST] <tadau> Cracki: ty very much :-) [11:23:30 CEST] <Plop2> hi all [11:24:15 CEST] <Plop2> is someone has a pointer to a documentation or even an exmaple to explin how to encode H264 stream form a series of images and send it through a network stream ? [11:24:45 CEST] <Plop2> All that i've tried does not work for now... [14:04:51 CEST] <dragmore88> hi! anyone know how i can extract audio channel 1 and 2 (FL, FR) from a prores stream and output it as a stereo track through amerge ? Cant seem to get the syntax to work.. [14:16:07 CEST] <vlt> dragmore88: What have you tried so far? [14:38:11 CEST] <dragmore88> vlt: -vn -filter_complex "[0:7][0:8]amerge=inputs=2[aout]" -map "[aout]" -c:a pcm_s24le [14:39:08 CEST] <dragmore88> vlt: not happy with the quality, should prolly use the 6 first tracks, and make a downmix of those [14:44:54 CEST] <dragmore88> Another question from me; can ffmpeg onthe fly igmp join a 7 SPTS multicast group and repackage it as mp4 and HTTP it out ? [14:46:03 CEST] <dragmore88> ismv [14:46:58 CEST] <BtbN> "http it out"? [14:47:06 CEST] <BtbN> mp4 is not streamable [14:47:23 CEST] <BtbN> and running an http server to serve stuff is up to you [14:47:39 CEST] <bencoh> ismv is a bit better though [14:49:34 CEST] <dragmore88> the target is for Unified Streaming platform [14:50:12 CEST] <dragmore88> we have harmonic electra transcoders today, but they can only output mulitple profiles via multicast.. unified streaming expects ismv mp4 as input [14:50:30 CEST] <dragmore88> unified streaming would be the origin server [14:51:14 CEST] <dragmore88> so if i could use ffmpeg inbetween and take it from multicast SPTS to unicast ismv [14:52:25 CEST] <Nacht> We're getting ISMV streams from Electra Harmonics on our Unified. So it should be possible ? [14:52:27 CEST] <DHE> ffmpeg can join multicast. not sure about ismv output specifically. isn't that microsoft smoothstreaming? [14:52:38 CEST] <Nacht> Afaik the people who send it aren't using FFMPEG in between [15:03:42 CEST] <dragmore88> Nacht, what exact product are u using and version ? (that can produce ISMV compliant streams over http ? [15:05:10 CEST] <dragmore88> http://docs.unified-streaming.com/documentation/package/content_description… [15:06:54 CEST] <dragmore88> http://docs.unified-streaming.com/faqs/factsheet.html#supported-ingest [15:07:28 CEST] <dragmore88> it only says fragmented MP4 [15:07:36 CEST] <dragmore88> as inout [15:07:38 CEST] <dragmore88> input* [15:08:01 CEST] <dragmore88> haha.. ffmpeg is mentioned in the supported encoders ;) [15:08:04 CEST] <Nacht> Let's see, they are/were using Electra VS with Firmware 05.00.01, we're running 1.7.19 of Unified Origin [15:08:29 CEST] <Nacht> Yeah Unified even has a Live Encoder sample on their support pages using FFMPEG [15:08:36 CEST] <dragmore88> url ? [15:08:54 CEST] <Nacht> http://docs.unified-streaming.com/installation/evaluation.html#live-demo [15:28:09 CEST] <dragmore88> nacht, thx [15:49:27 CEST] <nicolas17> tadau: btw, if ffmpeg crashes or similar, you get your problem of an unusable .mp4, but if you abort it properly (pressing q or Ctrl-C) it will write the moov atom [16:27:49 CEST] <pavel> Hello! When i try to use h264_vaapi encoder with quality > 2, I see error: "Failed to end picture encode issue: 18 (invalid parameter).". What I doing wrong? [16:28:43 CEST] <pavel> Documentation says that quality may be in range 0..8 [16:33:35 CEST] <jkqxz> Documentation says that quality may be in some driver-determined range. Probably your driver only supported 0-2. [16:35:02 CEST] <pavel> Hmm, thanks [16:35:45 CEST] <jkqxz> (If you use a more recent version it checks the range and will give you a better error message.) [16:53:33 CEST] <mcJack> Hi, I try to create a multichannel ogg file from 28 wav files. It worked in several instances, but the same command triggers an assert in some cases, here is the paste: https://pastebin.com/cvz6TWk0 [16:53:59 CEST] <mcJack> This is the assert: Assertion outlink->channel_layout == out_layout || !outlink->channel_layout failed at libavfilter/af_aresample.c:174 [16:54:14 CEST] <mcJack> Has anybody an idea, how that can be resolved? [16:57:11 CEST] <Nacht> mcJack: What do you use that needs to have 28 different channels ? Just curious [16:57:48 CEST] <mcJack> it's a dynamic music library, the stereo stems are mixed on the fly [16:58:38 CEST] <mcJack> before whe had the stems stored individually, but having one multi channel file saves a lot of CPU on the client's side [16:59:49 CEST] <Nacht> I see. Thanks for shedding some light on that :) [17:00:02 CEST] <mcJack> my pleasure :-) [17:01:01 CEST] <c_14> mcJack: try updating your ffmpeg [17:01:04 CEST] <c_14> the one you have is pretty old [17:01:10 CEST] <c_14> http://johnvansickle.com/ffmpeg/ [17:01:21 CEST] <c_14> try a static build [17:02:40 CEST] <mcJack> I see, it's the one Ubuntu-16.04 selects& I'll build it manually and see, if that helps& thanks so far [17:10:34 CEST] <mcJack> c_14: I tried the static builds, 3.3, unfortunately the error stays the same: https://pastebin.com/5mxmPUBn [17:10:58 CEST] <mcJack> trying nightly build next [17:13:08 CEST] <mcJack> and again, just the linenumber changes, that shows me at least I am not running the same thing each time ;-) [17:16:03 CEST] <c_14> hmm [17:16:05 CEST] <c_14> worth a shot [17:16:17 CEST] <mcJack> sure, thanks :-) [17:21:34 CEST] <mcJack> Here an example when it works: https://pastebin.com/MKW6cg8W [17:26:27 CEST] <c_14> Does vorbis have a maximum number of channels? [17:27:17 CEST] <c_14> hmm, up to 255 [17:32:27 CEST] <c_14> You can try setting -och 56 -osr 48k ? [17:32:44 CEST] <c_14> Because the assertion is something with aresample [17:33:42 CEST] <c_14> (so I'm just trying to override some of the things it would otherwise autodetect) [17:33:53 CEST] <c_14> You can check in ffmpeg-resampler(1) [17:34:47 CEST] <mcJack> cheers, I'll try that& had experimented with ac, but that didn't do anything [17:36:23 CEST] <c_14> maybe also set -ocl 56c [17:36:40 CEST] <c_14> possibly with a capital C instead of the lowercase one [17:36:51 CEST] <c_14> (describen in ffmpeg-utils(1) in the Channel Layout section) [17:44:16 CEST] <mcJack> didn't change anything. -ocl doesn't get through the parser, I might use it wrong [17:45:40 CEST] <mcJack> ah, sorry, 56c is "Error setting option ocl", but 56C renders: [SWR @ 0x4cbc520] Unable to parse option value "56C" as channel layout [17:51:26 CEST] <c_14> *sigh* [17:51:30 CEST] <c_14> that's a bug [17:51:33 CEST] <c_14> I might fix it [17:51:50 CEST] <c_14> But it won't help you immediately [17:52:11 CEST] <c_14> try just -ocl 56 [17:52:19 CEST] <c_14> If I read the code correctly, that should work [17:53:15 CEST] <mcJack> jepp, that parses correectly, but it still asserts :-/ [17:53:40 CEST] <mcJack> do you have an idea, what the root cause could be? [17:54:27 CEST] <c_14> I'm just grasping at straws [17:55:03 CEST] <mcJack> I see& if you have an idea, I am happy to test anything you throw at me ;-) [18:03:35 CEST] <krvl> Hi all [18:06:24 CEST] <krvl> I have a problem with mpeg-dash streaming: the player stuck when it reaches the last fragment (I'm testing atm with dash.js library). Do I need to reload the manifest? [18:13:31 CEST] <azarus> Does anyone know how to enable x11grab on gentoo? [18:14:59 CEST] <kepstin> azarus: you'll need the xcb option enabled to get xcbgrab [18:15:11 CEST] <kepstin> (which is probably what you're looking for) [18:15:46 CEST] <azarus> kepstin: Yup, found it. x11grab seems deprecated. [18:16:22 CEST] <azarus> Thanks! [18:37:35 CEST] <azarus> What are some fast-to-encode video codecs? [18:38:03 CEST] <durandal_1707> utvideo and others [18:41:58 CEST] <mcJack> c_14: I can pass the assert, if I could set the output layout to 0? is that possible? And could that help me? [18:45:24 CEST] <c_14> you can try [18:45:56 CEST] <mcJack> how can I set that from the command line? ocl 0 doesn't work [18:50:38 CEST] <c_14> 0c maybe? [18:51:10 CEST] <c_14> ah, nvmd [18:51:16 CEST] <c_14> If it gets 0 it throws an error [18:51:53 CEST] <mcJack> Too bad& I was just wondering, why it is excluded from that assert& but probably because it was checked before... [18:55:22 CEST] <mcJack> Ok, I'll be back tomorrow& thanks so far! [18:58:11 CEST] <kbaegis> *sigh* Anyone know why aac (native) to aac (native) transcoding would fail from mkv -> mp4? [18:58:22 CEST] <kbaegis> works with the -an arg [18:59:17 CEST] <BtbN> can't just codec copy? [19:00:45 CEST] <kbaegis> https://pastebin.com/5FviNifW [19:01:20 CEST] <c_14> add -c copy [19:01:44 CEST] <c_14> I don't see why you'd need to reencode that [19:01:51 CEST] <kbaegis> Ahh, gotcha. [19:02:04 CEST] <kbaegis> Well, probably because I didn't know ffmpeg didn't handle that for me :) [19:06:56 CEST] <kbaegis> Umm [19:07:01 CEST] <kbaegis> What's the underlying issue though? [19:07:13 CEST] <kbaegis> What if I did want to xcode? [19:07:54 CEST] <kbaegis> Still seeing Too many packets buffered for output stream 0:1. [19:08:00 CEST] <kbaegis> (which is the audio) [19:09:48 CEST] <kbaegis> c_14? anyone? [19:10:20 CEST] <c_14> I have no clue [19:10:40 CEST] <c_14> ffmpeg usually also outputs a more helpful error [19:10:42 CEST] <c_14> but there is none [19:10:43 CEST] <kbaegis> How do I run a -vvv or debug in ffmpeg? [19:10:48 CEST] <c_14> -loglevel debug [19:10:54 CEST] <kbaegis> Awesome, ty [19:11:12 CEST] <kbaegis> Yeah, I can't make an avi with it (not that I'd want to), but I can strip the audio channel out into a separate mp3 [19:11:14 CEST] <kbaegis> Weird [19:17:13 CEST] <blaenk> is there a way to mix/combine two audio tracks in an mp4 into a single one? [19:33:56 CEST] <blaenk> got it, using amerge [19:34:22 CEST] <kepstin> hmm, depends what you're trying to do, you might want amix instead [19:34:49 CEST] <kepstin> if you have two stereo tracks, and you want them mixed together into a single stereo track, use amix. [19:35:37 CEST] <blaenk> why? [19:36:22 CEST] <c_14> amerge with 2 stereo files will give you one 4.0 file [19:36:29 CEST] <c_14> amix with 2 stereo files will give you one stereo file [19:36:59 CEST] <c_14> (by mixing the left channel from one file with the left from the other file and the rights etc) [19:38:03 CEST] <blaenk> trying to make sense of that. the two audio tracks are indeed stereo, and the result of using amerge seems to show a single stereo track [19:38:53 CEST] <blaenk> here's the mediainfo of the amerge result https://gist.github.com/anonymous/6c86c60231c37f4a6994ba4a135b76bf [19:39:28 CEST] <c_14> what was the command you used to create the file? [19:39:42 CEST] <blaenk> I'm also using -filter_complex, maybe that's doing it [19:40:08 CEST] <blaenk> sec [19:40:12 CEST] <blaenk> ffmpeg -i in.mp4 -filter_complex "[0:a]amerge=inputs=2[a]" -map 0:v -map "[a]" -c:v copy -c:a libmp3lame -ac 2 out.mp4 [19:40:35 CEST] <c_14> >-ac 2 [19:40:41 CEST] <c_14> you're downmixing the result [19:40:44 CEST] <blaenk> ah of course [19:40:57 CEST] <blaenk> so it's creating the 4.0 like you said, then downmixing [19:41:06 CEST] <blaenk> different from using amix to create a 2.0 to begin with? [19:41:28 CEST] <c_14> In this case probably not [19:41:31 CEST] <c_14> In a more complex case maybe [19:41:45 CEST] <blaenk> I'll try to form the equivalent amix command [19:44:49 CEST] <igracia> hey! posted a question in the forum here http://ffmpeg.gusari.org/viewtopic.php?f=11&t=3434&p=11061#p11061 [19:45:20 CEST] <igracia> it's related to offsetting videos in a mosaic built with hstack and vstack [19:46:21 CEST] <igracia> is there a way to make hstack show a black frame for the duration of the time specified in PTS-STARTPTS+{offset}? [19:46:35 CEST] <igracia> or this can only be achieved via overlay? [19:47:14 CEST] <c_14> just concat the inputs you want to delay with a color=black,trim=d=<duration> [19:48:19 CEST] <blaenk> ffmpeg -i input.mp4 -filter_complex "[0:a]amix=inputs=2[a]" -map 0:v -map "[a]" -c:v copy -c:a libmp3lame -ac 2 "mixed.mp4" [19:48:23 CEST] <blaenk> that look ok? [19:48:35 CEST] <igracia> hum, is that faster than using overlay? if I have 16 videos (4x4 matrix) I will need 15 concats [19:48:36 CEST] <blaenk> is it ok to leave the -ac 2 in there or is it having an unintended effect [19:49:48 CEST] <kbaegis> Here's an updated paste with the loglevel turned up: https://pastebin.com/8m0SxZrJ [19:50:54 CEST] <c_14> blaenk: you can leave it, but you don't need it [19:51:26 CEST] <blaenk> sweet. thanks c_14 [19:51:39 CEST] <kbaegis> Seeing a lot of "cur_dts is invalid" [19:52:22 CEST] <c_14> there's probably something funky with the input stream that the encoder dislikes [19:53:44 CEST] <kbaegis> c_14: Since I can split audio away from the file successfully as well as video, is there a way to remerge the two streams? [19:54:53 CEST] <c_14> yeah [19:54:59 CEST] <c_14> just list them individually as inputs [19:57:38 CEST] <kbaegis> I'll have to see if I have syncing issues, but maybe that will be the way to go [20:28:38 CEST] <dorvan> hi all [20:29:25 CEST] <durandal_170> hi [20:32:36 CEST] <dorvan> on a net camera: stream 2560x1440, 30fps, 8192k, high, as encoding parameters, create an mp4 with a 1mbyte/s (8mbit/s) so 60mbyte/minute video, parameters are not correlated in the netcam interface, how i can find the lossless settings reducing bitrate? [20:33:08 CEST] <nicolas17> dorvan: *lossless* settings will make the file larger than that [20:34:12 CEST] <dorvan> nicolasl7 those are the losslessy settings... i have to compress... and reduce the bandwidth. [20:35:43 CEST] <nicolas17> then you'll lose quality [20:35:44 CEST] <nicolas17> you can probably tweak it so the quality loss is not noticeable, but you'll lose quality :P [20:35:51 CEST] <nicolas17> just nitpicking on "lossless" terminology [20:37:21 CEST] <dunpeal> Hi. I have an MP4 ("m4b") file, with chapter marks. Is there a straightforward way to cut 5 minutes off the beginning of this file, while preserving the correct chapter indices? [20:40:57 CEST] <dorvan> nicolas17: obviously, looking to selectable params what i have prefer to change to reduce as possible, without a visible significant lossy? [20:42:33 CEST] <klaxa> if you can pass crf values, increase it so far you still "like" it [20:42:45 CEST] <klaxa> higher crf -> more quality loss, less bitrate [20:47:47 CEST] <nicolas17> dorvan: "lossless" has a specific meaning in video encoding, meaning literally lossless, same pixels in and out, that means very very high bitrate [20:49:03 CEST] <dorvan> nicolas17: i know.. i've explained what i want to say in the latest phrase. are you locked on "lossless" term? [20:49:54 CEST] <nicolas17> what klaxa said, use crf :) [20:57:07 CEST] <dorvan> it's a ffmpeg instance inside a network camera, i can set ONLY that settings... [21:00:00 CEST] <dorvan> so... restart :-D on a net camera ( <--- net cam! ): i have a stream of 2560x1440, 30fps, 8192k, high, as encoding parameters ( i can play with bitrate and profile firstly) this settings creates an mp4 with a 1mbyte/s (8mbit/s) so 60mbyte/minute video, parameters are not correlated in the netcam interface, how i can find the lossless as possible settings reducing bitrate? [21:01:55 CEST] <klaxa> repeating it doesn't make it any less wrong? [21:02:31 CEST] <klaxa> what is the setting you can influence exactly? [21:03:23 CEST] <nicolas17> reduce bitrate [21:03:40 CEST] <dorvan> maintaining quality as possible, [21:04:02 CEST] <dorvan> obviously all solutions are lossy [21:04:04 CEST] <nicolas17> if it starts looking bad, you may get improvements by changing the preset to a slower one, but it seems like you can't change preset and probably the camera doesn't have the CPU for it anyway [21:04:44 CEST] <klaxa> well just decrease the bitrate then? constant bitrate encoding is pretty bad though [21:04:52 CEST] <klaxa> it's not something where you can throw math at it [21:04:55 CEST] <klaxa> quality is subjective [21:05:59 CEST] <dorvan> seem looking to cam gui and manuale, setting are not directly correlated, and this it's not really possible... [21:08:02 CEST] <dorvan> klaxa: yes quality it's subjective but loking to the stream output you have to see the "same" so i refer to not visible differencies about quality [21:08:10 CEST] <dorvan> looking* [21:08:37 CEST] <nicolas17> if all you can tweak is the bitrate, there isn't much you can do [21:08:58 CEST] <nicolas17> obviously you could use lower resolution (width x height) or lower framerate :P [21:09:16 CEST] <klaxa> what do you want us to tell you here? "use magical parameter --pixie-dust and all your problems will be resolved"? [21:09:26 CEST] <nicolas17> what file size are you expecting to get? [21:10:00 CEST] <klaxa> for quality comparison you encode multiple samples and compare them by eye [21:10:27 CEST] <nicolas17> klaxa: oh but the camera settings don't have a way to set --pixie-dust! ;) [21:10:31 CEST] <klaxa> if you want to compare pixel by pixel, do that, but with lossy encoding there will always be differences in every frame if you change the bitrate [21:10:57 CEST] <dorvan> klaxa: opposite... playing with usable settings to get the best as possible with less delay and smallest file without downscaling or reduce framerate. [21:11:23 CEST] <nicolas17> dorvan: but the only settings you can change are image size, framerate, bitrate, and profile? [21:11:39 CEST] <dorvan> klaxa: ok with nude eyes you compare 4MP image with other? [21:11:52 CEST] <klaxa> with what else [21:11:53 CEST] <dorvan> at 30fps? ..... [21:12:04 CEST] <klaxa> do you have other visual organs? i don't :P [21:12:38 CEST] <klaxa> if you really want to you can compare them with ssim and/or psnr [21:12:58 CEST] <nicolas17> why get more quality if you won't *see* the difference? [21:13:15 CEST] <dorvan> oh fuck*** probably you check video sources at fps read the bytes directly and comparing they... :-) [21:13:21 CEST] <nicolas17> is it in case some day you need to zoom in on the video to see a detail? in that case, do the comparison zoomed in now [21:14:28 CEST] <dorvan> nicolas17: i have to reduce delay mantaining a 4MP image at 30fps and video smooth, i have only those parameters to play with... [21:15:35 CEST] <nicolas17> if I understood correctly, the only settings you can change are image size, framerate, bitrate, and profile [21:15:47 CEST] <dorvan> firstly changeable params -> bitrate, and profile [21:16:01 CEST] <dorvan> then... image size, framerate, [21:16:08 CEST] <dorvan> as last option [21:16:24 CEST] <nicolas17> you don't want to change image size (downscale) or frame rate, profile is already "high", so all you have left is reducing the bitrate [21:16:56 CEST] <klaxa> in fact, bitrate is the only factor affecting filesize [21:17:31 CEST] <nicolas17> klaxa: if he had access to 'preset' he could make it slower while reducing bitrate, to *maybe* keep the same quality [21:17:50 CEST] <klaxa> bitrate would still be the only factor affecting filesize [21:17:54 CEST] <nicolas17> yep [21:18:06 CEST] <nicolas17> dorvan: what file size are you expecting to get? [21:18:48 CEST] <dorvan> nicolas17: i think 20% less then now [21:19:22 CEST] <nicolas17> so 48MB/s? [21:19:23 CEST] <nicolas17> er [21:19:29 CEST] <nicolas17> so 48MB/hour? [21:19:30 CEST] <dorvan> profile can help me to reduce delay plus with bitrate reduction? [21:19:34 CEST] <nicolas17> I keep mixing things up [21:19:35 CEST] <nicolas17> /minute! [21:19:48 CEST] <dorvan> i hope more... it's for minute... [21:20:08 CEST] <dorvan> because seems too large for the quality acquired by cam sensor... [21:20:13 CEST] <nicolas17> you're getting 60MB/minute now, 20% less is 48MB/minute [21:20:33 CEST] <dorvan> i yes, something like this i hope... [21:20:57 CEST] <dorvan> i have 1mbit/s steps in the selector.. [21:21:12 CEST] <nicolas17> 48MB/minute is about 6711k bitrate [21:22:12 CEST] <dorvan> i have 6mbit/s so 46mbyte/m [21:22:19 CEST] <dorvan> or less... [21:35:07 CEST] <dorvan> nicolas17: I'm trying with baseline profile and 6mbit/s bandwidth [21:44:11 CEST] <acos> Good afternoon [21:45:51 CEST] <acos> I am having some issues with trying to merge videos. But before that how can I fix dts errors and choppy playback? [21:59:54 CEST] <durandal_170> acos: what container? [22:00:34 CEST] <acos> Avi h264 [22:01:08 CEST] <acos> It says dts non contiguous. [22:01:36 CEST] <acos> And keeps spamming the console. The file sticks on playback during some parts. [22:03:44 CEST] <acos> durandal_170: it also converted the file to 1920x1088 :( [22:04:52 CEST] <durandal_170> avi is crap [22:05:23 CEST] <acos> And frame rate is 28.662420 [22:05:43 CEST] <acos> The video editor I am using is limited. Wasn't sure what format to export too [22:27:34 CEST] <durandal_170> acos: what else it can export? [22:28:10 CEST] <acos> Wmv..... some you have to pay for to unlock in the software. [22:28:24 CEST] <acos> I Wil have more info tonight busy now [22:29:27 CEST] <durandal_170> wmv is asf and it may be better but dunno what it supporrts [22:30:09 CEST] <JEEB> in theory you can stick almost whatever you want into ASF, but officially it's just WMV and WMA derivatives [22:30:59 CEST] <klaxa> in theory, it seems, people hack just about everything into avi too :P [22:33:31 CEST] <thebombzen> RIFF stuffs [23:52:13 CEST] <DHE> acos: officially AVI does not support bframes. when transcoding set that to 0 [23:55:29 CEST] <acos> Hmmmm. Not sure. What format should I even be using ? [00:00:00 CEST] --- Wed Aug 30 2017

1 0

ffmpeg-devel.log.20170828
by burek 29 Aug '17

29 Aug '17

[03:40:41 CEST] <rcombs> wow this samsamsam reply [03:41:08 CEST] <rcombs> >Anyway we are talking about safety but parser for mp4 atoms missing checking and there is quite easy to make segfault of the libavformat when try to prepared mp4 file. [03:41:08 CEST] <rcombs> >I understand that you want to have maximum safety with new code but I hope you know that ffmpeg at all is not safety. [14:10:22 CEST] <cone-396> ffmpeg 03Jun Zhao 07master:385cafb07ac1: lavc/vaapi_encode_h265: Enable VBR mode [14:10:23 CEST] <cone-396> ffmpeg 03Jun Zhao 07master:e4a6eb70f471: lavc/vaapi_encode: Change the slice/parameter buffers to dynamic alloc. [14:10:24 CEST] <cone-396> ffmpeg 03Mark Thompson 07master:b264810ef7a3: hevc: Add names for reserved NAL unit types [15:23:46 CEST] <JEEB> ah, `{"threads", "set the number of threads", OFFSET(thread_count), AV_OPT_TYPE_INT, {.i64 = 1 }, 0, INT_MAX, V|A|E|D, "threads"}` [15:29:03 CEST] <rcombs> I'm not entirely sure why that's set to 1 [15:29:18 CEST] <rcombs> ffmpeg.c (or is it ffmpeg_opt.c) sets it to 0, except when probing [15:29:20 CEST] <gh0st__> I had the same problem /w thread_count [15:37:58 CEST] <JEEB> yea, it sets to zero => nonzero return => "auto" [15:39:06 CEST] <BBB> back when the default was chosen, I believe someone (I cant remember who) complained that making the default zero (auto) would mean that the behaviour changed [15:39:14 CEST] <BBB> a trollwar followed [15:39:21 CEST] <BBB> and the end result was the default being 1, not 0 [15:40:46 CEST] <JEEB> I think you still have to poke around with threads for libvpx [15:40:51 CEST] <JEEB> since for it zero == one [15:42:59 CEST] <ubitux> i thought <whatever> == one with libvpx [15:45:44 CEST] <JEEB> vp9 encoder lately'ish enabled threading [15:45:50 CEST] <JEEB> as in, within N months [16:10:25 CEST] <kierank> eugh [16:10:26 CEST] <kierank> av_log_set_level(AV_LOG_DEBUG); [16:13:32 CEST] <kierank> avfilter_graph_alloc_filter [16:13:36 CEST] <kierank> just silently dies [16:13:36 CEST] <kierank> lovely [16:13:43 CEST] <JEEB> o_O [16:53:35 CEST] <durandal_170> kierank: really? [16:53:58 CEST] <kierank> if filter is not compiled in yes [17:10:58 CEST] <JEEB> ah [17:11:16 CEST] <JEEB> still probably not supposed to happen :) [17:17:55 CEST] <durandal_170> JEEB: you working on that? [17:24:11 CEST] <wm4> does it return an error code? [17:24:18 CEST] <wm4> (which of course will be completely useless) [17:24:59 CEST] <nevcairiel> its not like log messages are particularly helpful for api users =p [17:26:02 CEST] <kierank> wm4: the av_get_filter does [17:27:54 CEST] <BBB> ubitux: libvpx has tile threading (enc and dec, afaik) [17:28:22 CEST] <BBB> ubitux: ffvp9 single-threaded is almost as fast as libvpx with 2 tile threads, but still [17:28:25 CEST] <BBB> its something [17:32:08 CEST] <JEEB> durandal_170: nope, got onto train and going home :p [17:36:46 CEST] <rcombs> wm4: inb4 error code -1 [17:39:08 CEST] <BBB> error code -1 still beats randomly palced abort()s [18:06:39 CEST] <RiCON> BtbN: http://sprunge.us/cCiW [18:08:36 CEST] <atomnuker> iive: why do you have to mess with pic at all in your code? [18:09:18 CEST] <atomnuker> none of the asm I've written has had to deal with that [18:12:14 CEST] <iive> because I have a "table" lookup. so addr+reg, [18:15:46 CEST] <iive> when using pic, you can have only [rpi+const] no second register in there. [18:16:01 CEST] <iive> rip [18:16:50 CEST] <atomnuker> const_int32_offsets? [18:17:05 CEST] <atomnuker> what does $-const_int32_offsets mean? [18:17:08 CEST] <iive> masks [18:17:36 CEST] <iive> $ is the current address, it just calculates the offset from the start of the define. [18:18:25 CEST] <atomnuker> so you pick const_float_0_5 or const_float_1 or const_float_sign_mask on runtime? [18:18:41 CEST] <iive> what do you mean by pick? [18:19:06 CEST] <atomnuker> load one without a jump into a register [18:19:22 CEST] <iive> ?? [18:19:58 CEST] <iive> you mean, like `addps m0, [const_blabla]` ? [18:20:16 CEST] <atomnuker> e.g. in c code memcpy(out, stack_start + selection*sizeof(const_float_0_5), sizeof(const_float_0_5)) [18:20:41 CEST] <iive> that's even more confusing. [18:20:57 CEST] <atomnuker> what are you looking up and in which table? [18:21:16 CEST] <iive> oh [18:21:37 CEST] <iive> the sign mask is also used as padding mask [18:22:14 CEST] <iive> to filter out the extra padding of the input data and pad the tmpX[N+1]=0.0 [18:22:31 CEST] <iive> [N] actually too. [18:23:30 CEST] <atomnuker> so what do you look up? [18:24:39 CEST] <iive> the mask [18:25:41 CEST] <atomnuker> but its 0x80000000 everywhere [18:26:42 CEST] <iive> it's unaligned access and it reads into the follow up zeroes [18:27:17 CEST] <iive> aka, padding=0, (aligned access) would load the whole sign mask. [18:27:55 CEST] <iive> padding=(mmsize-1), would load only one 0x80000000 and the rest is zero. [18:28:15 CEST] <atomnuker> there's vmaskmov for this, isn't there [18:28:26 CEST] <iive> no [18:28:40 CEST] <iive> it needs the mask beforehand [18:31:50 CEST] <atomnuker> movaps m2, [const_float_sign_mask] [18:32:16 CEST] <atomnuker> where do you do the lookup into const_float_sign_mask? [18:32:43 CEST] <iive> and maskmov is around 3000 cycles on Ryzen. [18:34:11 CEST] <iive> movups m2, [pic_base_const_align_abs_edge + r4 - mmsize] [18:39:09 CEST] <atomnuker> if you know that the padding is never going to be larger than mmsize couldn't you just pcmpeqd [18:39:54 CEST] <atomnuker> rather PCMPGTW [18:40:24 CEST] <atomnuker> where you have 0, 1, 2, 3 in the second register and the padding splatw'd across the first register [18:41:08 CEST] <atomnuker> so as padding increases so would the resulting parts of the register be filled with 0 [18:41:20 CEST] <atomnuker> so then you just AND them to look right [18:43:01 CEST] <iive> it's a lot more instructions [18:43:20 CEST] <iive> and it goes over integer domain and back [18:44:28 CEST] <iive> get the padding from gprs into m0 [18:44:35 CEST] <iive> broadcast it [18:44:43 CEST] <iive> load offsets [18:44:51 CEST] <iive> compare [18:45:01 CEST] <iive> and with sign [18:47:45 CEST] <iive> then move result from int to float domain, and hope you get just 1 cycle penalty [18:50:32 CEST] <atomnuker> integer domain and back penalty is missing from anything newer than 2011 and its a lot less messy than touching pic yourself [18:50:47 CEST] <atomnuker> besides you do this once at init [19:14:25 CEST] <iive> what is the problem with pic? [19:27:09 CEST] <iive> atomnuker: what is your problem with pic? [20:00:39 CEST] <iive> atomnuker: [20:13:38 CEST] <durandal_170> atomnuker is speechless [20:13:41 CEST] <atomnuker> iive: I don't like it because its messy and can be avoided [20:15:16 CEST] <iive> well, if you have something that is faster and works the same, then I'm on to it [20:15:34 CEST] <iive> if you want to make the code bigger and slower, for no real reason or benefit [20:15:41 CEST] <iive> then NO [20:44:43 CEST] <atomnuker> if I have something that's slower and bigger when put into your code I'll rewrite the entire search then [20:51:21 CEST] <iive> good luck with that. [21:54:29 CEST] <kierank> wm4: oh wow that email [21:56:19 CEST] <BtbN> how do you even mess up a reply that bad? [21:56:57 CEST] <wm4> well there is a user-agent [21:57:35 CEST] <wm4> "GWP-Draft" [21:57:39 CEST] <wm4> whatever that is [21:58:14 CEST] <BtbN> Google gives nothing useful for that [22:00:12 CEST] <kierank> lol [22:33:23 CEST] <philipl> wm4: "...so I wrote my own mail client." Now you have two problems. [22:36:05 CEST] <philipl> https://generatewp.com/allow-multiple-recipients-wordpress-mail/ [22:36:07 CEST] <philipl> I bet that's it. [22:36:11 CEST] <philipl> and that's terrifying. [22:39:22 CEST] <wm4> what the hell [22:42:56 CEST] <JEEB> lol [22:45:40 CEST] <Mavrik> ... how? [22:45:56 CEST] <Mavrik> "Let me use my WordPress as a mail client?" O.o [22:51:29 CEST] <atomnuker> if the chromium folks want to save space they can just clean up the code of libvpx [22:51:45 CEST] <atomnuker> abstraction over abstraction over abstraction to do a dct [22:52:10 CEST] <atomnuker> additional 2d dcts on top of that which are only used for rdo [22:53:01 CEST] <nevcairiel> for odd reasons they get set strict size constraints for their thrid-party plugins, no matter what they do [22:54:28 CEST] <atomnuker> libvpx is third party too [22:54:31 CEST] <Mavrik> Probably some silly thing like lack of space on Chromecast or Home devices. [22:55:09 CEST] <nevcairiel> atomnuker: its still a single library though, and they probably expect entire ffmpeg to be the same size as vpx =p [23:00:56 CEST] <kierank> at the same time it's very difficult to remove junk from ffmpeg [23:01:12 CEST] <jamrial_> they are already removing two thirds of the stuff in libavutil in a custom way, leaving only md5, crc and the avcodec relevant modules [23:02:48 CEST] <atomnuker> kierank: its very easy to remove certain things [23:03:05 CEST] <atomnuker> yet for some like lavr its very hard (thanks nevcairiel) [23:03:13 CEST] Action: kierank uses lavr [23:03:19 CEST] <atomnuker> and you [23:03:47 CEST] <kierank> hmmm seems --disable-ffserver is the culprit [23:04:03 CEST] <kierank> if you add that then junk like ffm muxer and asf goes away [23:04:24 CEST] <jamrial_> ffm sure, but asf how? [23:04:55 CEST] <kierank> oh lets do this fairly and use a new ffmpeg [23:05:01 CEST] <jamrial_> isn't that wmv? [23:05:07 CEST] <nevcairiel> it is [23:05:22 CEST] <nevcairiel> but who knows what ffm all pulls in [23:07:09 CEST] <kierank> --disable everything pulls in: [23:07:10 CEST] <kierank> asf mov mpegts rm rtsp [23:07:30 CEST] <kierank> cuda cuvid nvenc [23:07:41 CEST] <kierank> most of it goes away with --disable-ffserver [23:07:49 CEST] <kierank> except that cuda stuff which I explicitly remove [23:08:01 CEST] <BtbN> why does that not fall under disable everything? [23:08:02 CEST] <jamrial_> ffserver_select="ffm_muxer rtp_protocol rtsp_demuxer" [23:08:06 CEST] <jamrial_> rtp probably pulls the asf stuff [23:08:41 CEST] <jamrial_> BtbN: disable-everything doesn't disable ffmpeg/ffplay/ffprobe/ffserver [23:08:48 CEST] <jamrial_> that's done by disable-programs [23:09:03 CEST] <BtbN> cuda/nvenc I mean [23:09:13 CEST] <BtbN> I see no reason why it should be enabled in a disable-everything build [23:09:37 CEST] <kierank> why can't --disable-everything disable programs [23:10:22 CEST] <nevcairiel> because thats what --disable-all does, i guess [23:10:27 CEST] <nevcairiel> (confusing, i know) [23:10:45 CEST] <kierank> yeah just seen that [23:10:46 CEST] <kierank> news to me [23:10:51 CEST] <nevcairiel> speaking of odd build things, configure on windows enables x11 [23:10:58 CEST] <nevcairiel> which apparently has no system dependencies whatsoever [23:11:11 CEST] <JEEB> hah [23:11:12 CEST] <nevcairiel> doesnt cause any issues either [23:11:15 CEST] <nevcairiel> but its just there [23:11:20 CEST] <jamrial_> really? it doesn't for me [23:11:22 CEST] <kierank> note --disable-all still does [23:11:22 CEST] <kierank> cuda cuvid nvenc [23:11:44 CEST] <kierank> cuda_deps_any="dlopen LoadLibrary" [23:11:50 CEST] <kierank> everyone has those so I guess it works [23:11:55 CEST] <nevcairiel> jamrial_: xlib to be precise [23:12:20 CEST] <nevcairiel> https://pastebin.com/wuT8uzJZ shrug [23:13:41 CEST] <jamrial_> kierank: not really, but it doesn't hurt for those that don't since it just fails if you try to use it [23:14:13 CEST] <kierank> but it means shipping bloat [23:14:13 CEST] <jamrial_> nevcairiel: oh lol, i see CONFIG_XLIB=yes in my config.mak [23:15:45 CEST] <jamrial_> nevcairiel: https://pastebin.com/Ptx0HR2P maybe [23:17:48 CEST] <nevcairiel> yeah guess its just never disabled [23:17:57 CEST] <jamrial_> grep -r CONFIG_XLIB * --> no results [23:18:19 CEST] <nevcairiel> is it used as a dep for other things? [23:18:22 CEST] <nevcairiel> or just old? [23:18:30 CEST] <jamrial_> within configure, for those headers [23:19:15 CEST] <nevcairiel> seems never used anywhere [23:19:24 CEST] <jamrial_> xv_outdev_deps="X11_extensions_Xvlib_h XvGetPortAttribute" [23:19:39 CEST] <nevcairiel> that sounds like a dumb way to do it [23:19:47 CEST] <jamrial_> probably [23:19:48 CEST] <nevcairiel> why not just depend on xlib [23:21:59 CEST] <BtbN> hm, so disable-everything does disable all the encoders/decoders [23:22:07 CEST] <BtbN> Don't understand how cuvid and nvenc survive that [23:22:52 CEST] <nevcairiel> it disables everything in COMPONENT_LIST, which doesnt include the libraries themself, only actuel encoders/decoders [23:23:12 CEST] <BtbN> But that should mean no actual code is left? [23:23:14 CEST] <kierank> https://www.irccloud.com/pastebin/Ng6t7Czt/ [23:23:20 CEST] <kierank> cuda stuff is in avutil [23:23:26 CEST] <nevcairiel> the avutil hwcontext stuff remains, indeed [23:23:52 CEST] <nevcairiel> could extend disable-everything to in clude those, especially the autodetected stuff [23:28:04 CEST] <wm4> funny, all this bullshit about not having autodetection by default (which severely confuses users), and it gets it wrong anyway [23:28:31 CEST] <wm4> you'd almost think autodetection everything by default is ok, and --disable-everything should just disable everything [23:28:52 CEST] <wm4> instead of using autodetection only "sometimes" and --disable-everything not actually disabling everything [23:29:14 CEST] <nevcairiel> i would like an option like --disable-external-shit [23:29:36 CEST] <nevcairiel> i dont want unexpected external deps on anything [23:29:46 CEST] <nevcairiel> but i dont want to have to deal with enabling all internal components again manually [23:30:23 CEST] <nevcairiel> these days I have to ldd binaries before i can be sure i can ship them [23:31:20 CEST] <nevcairiel> speaking of, i should probably make a new build and finally get off my ass and implement hw decoding on linux now that all the hwcontext stuff does all the hard work for me [23:33:04 CEST] <jamrial_> is this about $dayjob stuff? [23:33:29 CEST] <nevcairiel> yea [23:36:04 CEST] Action: kierank wants --disable-every-bloody-thing [23:37:45 CEST] <atomnuker> nevcairiel: why are you not using lswr? [23:38:39 CEST] Action: kierank wonders whether to troll atomnuker with that site [23:39:23 CEST] Action: kierank uses avr because it had public patch review [23:46:15 CEST] <nevcairiel> I dont particularly remember why I used lavr when I did, but spending time to change it is time i'm not getting back :) [23:46:50 CEST] <atomnuker> kierank: last time you told me you liked its API better now you tell me another reason [23:47:03 CEST] <kierank> not mutually exclusive [23:47:17 CEST] <atomnuker> I don't believe any of you has a good reason [23:47:22 CEST] <kierank> and during one of the many flamewars about this have gone on record about this [23:47:25 CEST] <kierank> on various MLs [23:49:45 CEST] <atomnuker> sure, I love reading outdated reasons which are irrelevant now on various topics [23:50:00 CEST] <atomnuker> kinda like, I dunno, "ffmpeg never removes things" [23:50:13 CEST] <kierank> ffmpeg pushes stuff without any public review [23:50:16 CEST] <kierank> like swresample [23:50:17 CEST] <kierank> hmmm [23:51:06 CEST] <atomnuker> sure, like people experienced in dsp are particularly common, especially those who know about resapling [23:51:37 CEST] <kierank> people should still have commented on the API [23:51:50 CEST] <atomnuker> its a decent API, I don't mind it [23:51:50 CEST] <kierank> at the time it was a copy paste of swscale... [23:52:07 CEST] <kierank> then it was patched after complaints to use avframe [23:53:34 CEST] <kierank> oh well north korea is firing missles [23:53:39 CEST] <kierank> see you all in the afterlife [23:54:02 CEST] <JEEB> kierank: my phone buzzed a lot during the last 30min :D [23:54:11 CEST] <kierank> ohshit [23:54:23 CEST] <JEEB> but it seems like it a) passed and b) broke down in three parts, is in the pacific ocean now [23:54:57 CEST] <JEEB> j-alert sent a message like "passed this area, if you find anything weird please do not go close to it and inform officials" [23:56:41 CEST] <gh0st__> kierank: "oh well north korea is firing missles", I hope to finish my assembly before that. =) [00:00:00 CEST] --- Tue Aug 29 2017

1 0

ffmpeg.log.20170828
by burek 29 Aug '17

29 Aug '17

[00:03:29 CEST] <DHE> that's been a feature request for a while.. [00:03:40 CEST] <DHE> what are you trying to accomplish exactly? [00:05:25 CEST] <selsta> so here is my current code: https://github.com/selsta/hlsdl/blob/master/src/hls.c#L292 [00:05:25 CEST] <selsta> problem is, I cant get the sample rate and the frame size because the audio is encrypted [00:06:40 CEST] <selsta> avformat_write_header() crashes because I dont have a sample rate [00:12:29 CEST] <DHE> huh... I always thought that mpegts encrypted in (up to) 184 byte frames [00:13:51 CEST] <JEEB> yea, the mpeg-ts layer is 188 byte packets [00:13:58 CEST] <selsta> its sample-aes hls encryption, not mpeg-ts encryption [00:14:16 CEST] <JEEB> and yea, you can just encrypt the payload in that case [00:14:24 CEST] <DHE> yes, with a 4 byte header [00:14:48 CEST] <DHE> ah, yes HLS does have another encryption mode. but ffmpeg only supports the full encryption option [00:15:17 CEST] <selsta> my program is a decrypter for that other encryption mode [00:15:27 CEST] <JEEB> anyways, not fully sure libavformat is the thing to use in this case since it's supposed to be dealing with unecrypted data after it goes through the demuxer. esp. if you want to keep the original mpeg-ts structure [00:15:56 CEST] <DHE> sounds more like you want to implement an HLS->MPEGTS converter that does the on-the-fly decryption and just provides ffmpeg with an IOContext (?) [00:16:20 CEST] <JEEB> (36 [00:16:51 CEST] <selsta> yess [00:17:19 CEST] <selsta> the code already works for one stream that I have [00:17:34 CEST] <selsta> but dosent work for another stream [00:19:42 CEST] <selsta> Im just out of ideas how I should implement this properly [00:21:14 CEST] <__jack__> HLS -> mpegts ? that's really easy, is not it ? you just need to parse the HLS playlist, curl (and decrypt) the files, and concat them (using cat for instance, so really a plain dummy concat) [00:22:20 CEST] <selsta> sample-aes decryption is more complicated I need the mpeg-ts packets [00:57:26 CEST] <gtxbb> hi [00:57:55 CEST] <stimple> hullo, trying to cut a mp4 with -ss and -t but the vid seems to lack a keyframe anywhere near where i want to cut [00:58:04 CEST] <stimple> hi gtxbb [00:59:13 CEST] <stimple> what format should i encode to let me cut with -ss and not have garbage at the beginning? [01:01:04 CEST] <gtxbb> wondering if i can ask for help lol [01:01:19 CEST] <gtxbb> stimple, hey im a bit of a noob too [01:01:32 CEST] <gtxbb> stimple, i was looking at -ss, you'll need to use -ts i tihnk [01:01:45 CEST] <gtxbb> stimple, you need to specify a time offset [01:02:33 CEST] <gtxbb> stimple, https://libav.org/avconv.html#Main-options [01:03:10 CEST] <gtxbb> sorry wrong page lol.. must be a ffmpeg equivalent i guess [01:03:11 CEST] <stimple> no ffmpeg option -ts [01:03:37 CEST] <gtxbb> https://ffmpeg.org/ffmpeg.html#Main-options [01:04:27 CEST] <gtxbb> i'm perusing tools... [01:04:39 CEST] <gtxbb> hmm not sure if I can use unix:// << is this a control socket? [01:05:14 CEST] <stimple> don't know [01:05:32 CEST] <Nitori> -ss description already says why that happens. you basically have to reencode the video. with simple copy it doesn't work [01:05:41 CEST] <stimple> ty [01:06:04 CEST] Action: gtxbb https://ffmpeg.org/ffmpeg-protocols.html#unix [01:06:09 CEST] <Nitori> so use -ss after the input (on the output) [01:07:05 CEST] <gtxbb> what can i use a unix local socket? [01:07:18 CEST] <gtxbb> is that a controller socket for command? [01:07:31 CEST] <gtxbb> (i can do this with vlc, can i do this with ffmpeg?) [01:08:06 CEST] <Nitori> what exactly? [01:19:39 CEST] <gtxbb> cant seem to find a way to use it.. my ffmpeg build supports it, anyone? [01:21:46 CEST] <DHE> it's a variant that's like TCP and local only and performs better when dealing with lots of data [01:25:29 CEST] <stimple> what's a good output format for video editing? there used to be something called huffyuv but i think that might exceed my space [01:25:39 CEST] <stimple> don't need perfect quality [01:27:52 CEST] <gtxbb> DHE, i want to use it, i'm trying to use it.. [01:28:02 CEST] <gtxbb> (i need it) [01:31:08 CEST] <gtxbb> echo help |nc -w 2 -U avconv.socket [01:31:08 CEST] <gtxbb> nc: unix connect failed: Connection refused [01:32:12 CEST] <stimple> i guess mjpeg [01:32:30 CEST] <stimple> maybe not [01:49:27 CEST] <DHE> huffyuv if you're using yuv colourspace. ffmpeg also provides its own variant of huffyuv and you can also try ffv1 [01:49:44 CEST] <stimple> ty! [01:53:21 CEST] <furq> ffv1 will be much smaller than huffyuv but also a bit slower [01:53:49 CEST] <furq> but if you need compatibility with premiere, final cut etc then ffv1 is tricky [01:54:03 CEST] <furq> ut video is probably the best thing if you need NLE compatibility [01:54:24 CEST] <dan2wik> Is there a way I can set which decoder to use? [01:54:46 CEST] <furq> -c before -i [01:54:59 CEST] <dan2wik> Oh, ok thanks [02:07:02 CEST] <dan2wik> I have a camera that can output h264 video, I am using v4l2 to access it, could I specify "-c:v h264_mmal" to use the Pi's hardware decoder? [02:07:19 CEST] <dan2wik> I'm still compiling ffmpeg so I'm unable to try it right now [02:21:06 CEST] <furq> yeah that should work [06:58:24 CEST] <basse_> hi anyone with experience capturing audio with ffmpeg and pulseaudio? I want to capture audio from a specific browser tab when I have multiple tabs open, by using -f pulse -i default, I capture all the sounds within the system, but I want to capture teh sounds of s single tab, any ideas? [13:44:32 CEST] <mozzarella> guys help [13:45:43 CEST] <meriipu> what happened to --enable-libnpp ? I have added these https://bpaste.net/show/f7125fe366da options, but recently I get a "libnpp not found"-error when building. It used to work as far as I remember. This is to get the scale_npp filter. [13:49:28 CEST] <meriipu> I have an npp.h in /opt/cuda/include/ (as well as nppi.h and npps.h). I have libnppc.so, libnppi.so, and libnpps.so in lib64 (though no libnpp.so that I can find, I can not remember if I used to have one). [13:50:48 CEST] <meriipu> the answer to https://stackoverflow.com/questions/41870137/ffmpeg-error-libnpp-not-found-… mentions something about a broken configuration script, but I do not quite understand the implications. [13:51:37 CEST] <JEEB> "--enable-libnpp" is at least the correct parameter in the configure script [13:52:10 CEST] <meriipu> (for what it is worth, it builds without --enable-libnpp all other things the same, but that does not make the filter available it seems). [13:52:10 CEST] <JEEB> check where it fails in ffbuild/config.log with regards to libnpp [13:53:03 CEST] <BtbN> The guy claiming configure to be broken is just talking nonsense. [13:53:27 CEST] <JEEB> yea, just check what the configure script fails with [13:53:36 CEST] <BtbN> The configure options name has no relation to the libraries it actually checks for. [13:53:55 CEST] <JEEB> people often jump into conclusions [13:54:05 CEST] <BtbN> If you are using the CUDA 9 RC SDK: They renamed one of the libraries there. Once it's released, I will update configure accordingly. [13:54:23 CEST] <JEEB> kek, changing names :D [13:54:54 CEST] <BtbN> They are intended to be bundled with the application, and not installed into the system [13:54:59 CEST] <BtbN> as such, they are free to rename them [13:55:19 CEST] <BtbN> And it also makes them kind of horrible to use in ffmpeg [13:56:33 CEST] <meriipu> it seems to consider the ones it found incompatible https://bpaste.net/show/9f4b57d33b3a [13:57:07 CEST] <BtbN> you're compiling 32bit, and CUDA is x86_64 [13:57:22 CEST] <meriipu> aaa [13:59:14 CEST] <meriipu> yes I remember some install flag change earlier that enabled the 32bit version as well so that is likely it [13:59:28 CEST] <meriipu> (that some other package I have wanted I think) [13:59:42 CEST] <BtbN> It's 100% clearly what's happening. Not only likely. [13:59:54 CEST] <BtbN> gcc is instructed to build in 32bit mode, and cuda is 64bit only [14:00:31 CEST] <meriipu> that makes sense thanks [14:13:21 CEST] <meriipu> seems to have been my (32+64bit) install of opencv wanting 32bit ffmpeg, causing 32bit ffmpeg to be built. Rebuilding only 64bit ffmpeg worked sucessfully. Thanks for the help [15:13:51 CEST] <Fyr> guys, when remuxing video with simple copying of the streams, a mjpeg image is marked as Video #2. [15:14:05 CEST] <Fyr> what is the option to mark it as attachment? [15:19:10 CEST] <JEEB> Fyr: it's side data as far as I know in the stream [15:19:17 CEST] <Fyr> yes [15:19:28 CEST] <Fyr> how do I set it as an attachment? [15:21:29 CEST] <JEEB> AV_DISPOSITION_ATTACHED_PIC [15:21:32 CEST] <JEEB> seems to be the thing [15:21:47 CEST] <JEEB> seems to be a flag in stream->disposition [15:22:01 CEST] <Fyr> thanks, I'll try that. [15:22:57 CEST] <Fyr> JEEB, there are many dispositions, however, there is none for image. [15:23:10 CEST] <Fyr> default, karaoke, forced etc. [15:24:13 CEST] <JEEB> you can see it if you git grep FFmpeg's code :P [15:26:12 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/avformat_8h.html#aa8e9704bcc842236ad04… [15:26:18 CEST] <JEEB> it's right there [15:26:24 CEST] <JEEB> just not sure how many muxers take it in [15:30:52 CEST] <Fyr> Unable to parse option value "attached_pic" [15:31:08 CEST] <Fyr> it's in the source code, however, there is no option for this define. [15:37:19 CEST] <JEEB> oh, you're using the cli? [15:37:22 CEST] <JEEB> nfi then :D [15:51:56 CEST] <Fyr> JEEB, do you happen to know how mux some stream into NULL? [15:52:16 CEST] <Fyr> I'll try to copy everything except or selected streams. [16:09:19 CEST] <rungcc_from_work> hi guys [16:09:26 CEST] <rungcc_from_work> could someone help me with something? [16:10:08 CEST] <rungcc_from_work> I'm trying to make ffmpeg create a 100% transparent 1920x1080 23.976fps video [16:11:06 CEST] <rungcc_from_work> but I'm not being able to find the right command, I'm trying a lot of things here and looking at the help files, but I'm confused as a MF. [16:19:19 CEST] <furq> rungcc_from_work: -f lavfi -i color=#00000000:s=1920x1080:r=24000/1001,format=yuva420p [16:21:51 CEST] <rungcc_from_work> hi furq, unfortunately this also generate a black video instead of a transparent one [16:22:03 CEST] <rungcc_from_work> at lease final cut identify it as black instead of transparent [16:28:40 CEST] <charly> hello, there is a simple way to convert an AVFrame (with all data) into AVPacket ? [16:30:10 CEST] <jsbilodeau> Hi all! What is the best way to add a klv stream (SMPTE 336M KLV Data Encoding Protocol Using Key-Length-Value) using libavformat in c++? I quickly read mxf.h mxf_enc.c and there is some mention about the klv. Would the best way to do this is to use AVIOContext and avio_w * () and get inspiration from mxf_enc.f? [16:55:21 CEST] <Trel> I was looking at the encoding options for libx264 and more specifically at two pass encoding. I'm curious, since I'm not entirely familiar with the program yet, but how would the 2 pass encoding be separated out into two distinct steps? [16:59:18 CEST] <furq> you run ffmpeg twice [16:59:48 CEST] <furq> assuming you actually want 2-pass, which is unlikely [17:02:56 CEST] <Trel> furq: I would want 2 pass, but I'm not sure how to do that as two commands. https://trac.ffmpeg.org/wiki/Encode/H.264#twopass I'm looking at the example there. I'm not sure what input would be on the second pass [17:03:59 CEST] <furq> the same as it would be on the first pass [17:04:10 CEST] <furq> the first pass writes a log file to the working directory [17:04:14 CEST] <furq> the second pass will automatically read from that [17:04:55 CEST] <furq> like it says, unless you're targeting a specific filesize then you shouldn't use 2pass with x264 [17:08:56 CEST] <Trel> I AM targeting a specific filesize. [17:09:08 CEST] <Trel> Is it the -pass 1 and -pass 2 that make it read/write the log [17:09:48 CEST] <c_14> yes [17:09:49 CEST] <kepstin> with -pass 1 it writes the log, with -pass 2 it reads it, yes. [17:10:15 CEST] <Trel> Cool, that's all I needed then ,thanks :) (I'm putting a video on the remaining space on a flash drive for family). [17:10:23 CEST] <Trel> Hence why I'm targeting size [17:38:40 CEST] <Fyr> guys, when remuxing, I set one of the streams as default, however, the output file has two streams set as default. how do I mark one of them as non-default? [17:46:33 CEST] <Fyr> Google doesn't know the answer. [17:51:48 CEST] <atomnuker> Fyr: -map "0:v"? [17:52:33 CEST] <Fyr> what? [17:53:17 CEST] <atomnuker> map the outputs you want manually [17:53:48 CEST] <Fyr> -i file -map 0:0 -map 0:3 -map 0:1 -map 0:11 -map 0:5 -c copy -metadata:s:v:0 language=English -metadata:s:a:0 language=English -disposition:a:0 default -metadata:s:a:1 language=Russian -metadata:s:s:0 language=English -disposition:s:0 default -metadata:s:s:1 language=Russian [17:54:31 CEST] <atomnuker> oh, I didn't read [17:54:51 CEST] <atomnuker> which streams are default? [17:55:00 CEST] <Fyr> both audio [17:57:33 CEST] <Fyr> atomnuker, how is it going with AAC? [17:58:10 CEST] <atomnuker> nowhere, I'm doing the opus encoder now [17:58:24 CEST] <atomnuker> I'm pretty sure s:v:0 is incorrect [17:58:39 CEST] <atomnuker> 0th stream's video's subtitle stream? [17:58:57 CEST] <Fyr> the problem is with audio streams. [17:59:36 CEST] <atomnuker> disposition is copied afaik [18:00:03 CEST] <atomnuker> so you need to 0 the russian streams's disposition if the input file has it as the default [18:00:04 CEST] <Fyr> then how to remove disposition? [18:00:18 CEST] <atomnuker> -disposition:a:1 0 [18:00:25 CEST] <Fyr> thanks [00:00:00 CEST] --- Tue Aug 29 2017

1 0

ffmpeg-devel.log.20170827
by burek 28 Aug '17

28 Aug '17

[00:25:22 CEST] <thebombzen> wm4: if I want to use vo_vulkan rn as a test, which development branch should I use (I mean instead of master) [00:26:51 CEST] <wm4> thebombzen: haasn's repo, vulkan branch [01:03:02 CEST] <cone-278> ffmpeg 03Martin Vignali 07master:435dd2ee4e08: configure: add avx2 enabled log [01:57:04 CEST] <graphitemaster> wm4, your sdl example in mpv-examples wrongly assumes fbo 0 is the default framebuffer (this won't work on android for instance where the default fbo is something else entierly) [01:57:17 CEST] <graphitemaster> you have to actually get the currently bound fbo instead and pass that handle into mpv_opengl_cb_draw [01:58:14 CEST] <graphitemaster> the iOS example is correct since it gets the framebuffer binding [03:10:57 CEST] <cone-278> ffmpeg 03James Almer 07master:257f0d09f7b4: avcoec/snowenc: silence some deprecation warnings [03:38:56 CEST] <iive> graphitemaster: you need to run `perf` as root [03:39:10 CEST] <iive> and `perf top` is what you might want to try first. [03:40:03 CEST] <graphitemaster> iive, I did [03:45:06 CEST] <iive> as kernel options, I think you need CONFIG_PROFILING and OPROFILE [03:45:54 CEST] <iive> is config_audio about SElinux? [03:46:04 CEST] <iive> config_audit [03:46:55 CEST] <iive> gtg, bbl [06:29:09 CEST] <hanna> graphitemaster: glslang also doesn't install itself properly and doesn't come with a pkgconfig file, at least not here - but that might be a packaging problem (it's not available in the official repos, apparently not for most other major distros as well - so I installed a third party package) [08:54:19 CEST] <cone-973> ffmpeg 03Paul B Mahol 07master:99b6e68441ce: avfilter/af_amix: do not request samples if inlink reached EOF [15:55:34 CEST] <BtbN> I somehow doubt that cmd length issue [15:55:39 CEST] <BtbN> that would have blown up way earlier [16:34:43 CEST] <rcombs> >PATCH v15 >still has a format-string vuln [16:35:00 CEST] <JEEB> did anyone bring it up? :D [16:35:03 CEST] <rcombs> I did, just now [16:35:05 CEST] <JEEB> ah [16:35:08 CEST] <JEEB> cool [16:35:24 CEST] <rcombs> I've responded to this guy's DASH patches so many times pointing out these things [16:35:34 CEST] <JEEB> \o/ [16:35:36 CEST] <rcombs> and every time he comes back with another one that has a slightly different format-string vuln [16:35:44 CEST] <rcombs> I don't understand how this happens [16:35:55 CEST] <JEEB> lol [16:37:52 CEST] <rcombs> what part of "don't pass file-derived data to snprintf()" doesn't he understand [16:37:59 CEST] <rcombs> is it the language barrier [16:38:20 CEST] <JEEB> possibly [16:38:59 CEST] <rcombs> but yeah unfamiliarity with that very basic principle makes me inclined to recommend multiple passes over this with a fine-toothed comb before it lands [16:39:15 CEST] <rcombs> (I've looked over it a few times and found some things, but I'd appreciate additional sets of eyes) [16:40:27 CEST] <JEEB> I'll try to take a look at it some time soon, although I've tried to keep away from the XML side of DASH which is what that mostly touches :D [16:40:51 CEST] <rcombs> he's also switched from using av_asprintf() to snprintf()+av_malloc()+snprintf() now [16:41:01 CEST] <rcombs> which is weird, because that's literally what av_asprintf() is [16:41:12 CEST] <JEEB> yea... [16:48:26 CEST] <ubitux> av_asprintf is not in libav [16:49:03 CEST] <ubitux> that might be related [16:49:09 CEST] <JEEB> I don't think that patch was posted on libav? [16:50:09 CEST] <JEEB> yea, don't see it on libav-devel [16:50:30 CEST] <ubitux> dunno, i added it in 2011 in ffmpeg [17:21:58 CEST] <cone-809> ffmpeg 03Paul B Mahol 07master:2ce43274e392: avfilter/vf_zoompan: switch to activate [17:21:58 CEST] <cone-809> ffmpeg 03Paul B Mahol 07master:bf39f7eadc68: avfilter/vf_zoompan: parse zoom,x and y expression during initialization [17:32:27 CEST] <ubitux> v2 fixed: [...] "use API from snprintf to av_asprintf" [17:32:40 CEST] <ubitux> he probably rolled back because he has troubles with git [17:33:10 CEST] <ubitux> or maybe that's simply an old patch [17:36:07 CEST] <jamrial> ubitux: btw, got the major bump working, so we can either apply it at any point after 3.4 is released (michael and marton balint wanted that release before the bump), or once we resume with the merges [17:43:27 CEST] <ubitux> i won't work on the merge soon [17:44:45 CEST] <jamrial> alright. i'll send the patchset this week then [17:49:42 CEST] <jamrial> you got no news from the dashenc guy either? [17:58:12 CEST] <j-b> BBB: pong [18:10:57 CEST] <BBB> j-b: nevermind, already figured things out on #videolan [18:12:03 CEST] <cone-809> ffmpeg 03Marton Balint 07master:76a8b5e7adbb: avdevice/decklink_dec: fix signed and unsigned comparison warning [18:12:05 CEST] <cone-809> ffmpeg 03pkviet 07master:84ee6512ed70: avdevice/decklink_enc: enable 16 output channel [18:12:05 CEST] <cone-809> ffmpeg 03Maksym Veremeyenko 07master:2634927fe30e: lavd: implement NewTek NDI input/output device support [18:30:13 CEST] <durandal_1707> why is there no native decoder for speex codec? [18:31:50 CEST] <jamrial> same reason there's none for celt i guess, no real interest/use [18:35:14 CEST] <RiCON> the celt one could be harvested from opus, probably [19:29:47 CEST] <atomnuker> nah, incompatible [19:37:00 CEST] <cone-809> ffmpeg 03Michael Niedermayer 07master:7ec414892ddc: avformat/hls: Fix DoS due to infinite loop [19:37:01 CEST] <cone-809> ffmpeg 03Yi and *®() 07master:7f9ec5593e04: avformat/asfdec: Fix DoS due to lack of eof check [19:37:02 CEST] <cone-809> ffmpeg 03Yi and *®() 07master:7e80b63ecd25: avformat/cinedec: Fix DoS due to lack of eof check [19:37:03 CEST] <cone-809> ffmpeg 03Yi and *®() 07master:124eb202e706: avformat/rmdec: Fix DoS due to lack of eof check [19:37:04 CEST] <cone-809> ffmpeg 03Yi and *®() 07master:96f24d1bee7f: avformat/rl2: Fix DoS due to lack of eof check [19:37:05 CEST] <cone-809> ffmpeg 03Michael Niedermayer 07master:4f05e2e2dc1a: avformat/mvdec: Fix DoS due to lack of eof check [19:40:49 CEST] <kierank> oh lord [19:40:52 CEST] <kierank> that patchset [19:43:18 CEST] <jamrial> the author name and email is wtf [19:44:21 CEST] <jamrial> michaelni: should the error in those be AVERROR_EOF? [19:44:46 CEST] <jamrial> shouldn't [20:01:22 CEST] <michaelni> jamrial, some of the patches have 2 authors, which is hard to write cleanly in git [20:02:49 CEST] <michaelni> about the error codes, a file truncated in the middle of the header is invalid and it is EOF. I can change it t EOF and post a patchset if that is preferred [20:03:32 CEST] <jamrial> ah. if it's in the middle of the header then no, it's fine as is [20:04:27 CEST] <jamrial> and IMO, it would have been better to choose one name/email for the author field, then mention the other in the commit message [20:29:35 CEST] <michaelni> durandal_1707, 2ce43274e39295e3965c51dcfaf802628a5929f9 causes Assertion !(filter->filter->flags & (1 << 16) && filter->filter->activate) failed at libavfilter/avfilter.c:1472 [20:30:13 CEST] <michaelni> ./ffmpeg -f lavfi -i testsrc -vf zoompan -vframes 5 -y a.avi [20:31:08 CEST] <durandal_1707> michaelni: just remove flag from zoompan for now [20:53:00 CEST] <cone-809> ffmpeg 03Michael Niedermayer 07master:eefb68c9c335: avcodec/sbrdsp_fixed: Fix undefined overflows in autocorrelate() [20:53:01 CEST] <cone-809> ffmpeg 03Michael Niedermayer 07master:0181b202cc42: avcodec/aacpsdsp_template: Fix undefined integer overflow in ps_add_squares_c() [20:53:02 CEST] <cone-809> ffmpeg 03Michael Niedermayer 07master:aa26258faa97: avfilter/vf_zoompan: remove AVFILTER_FLAG_SUPPORT_TIMELINE_GENERIC [21:09:39 CEST] <cone-809> ffmpeg 03Timo Rothenpieler 07master:ef0c6d9b01de: libavutil/opencl: fix potential null dereference [00:00:00 CEST] --- Mon Aug 28 2017

1 0

ffmpeg.log.20170827
by burek 28 Aug '17

28 Aug '17

[00:44:32 CEST] <FishPencil> Does librtmp provide any additional features in FFmpeg than just including gmp? [02:21:17 CEST] <wiak> is there a way to get ffmpeg not to quit when there is no rtmp input stream? so it just simply stays open until there is stream again? [02:22:21 CEST] <c3r1c3-Win> wiak: My way around that was to write a script that would cycle back to the beginning and start ffmpeg anew whenever it quit. [02:26:00 CEST] <wiak> c3r1c3-Win okey something like my ninjaservice ;P https://github.com/nwgat/ninjaservice/blob/master/ninjaservice.py [02:47:30 CEST] <c3r1c3-Win> wiak: I wrote a bash script, but if python works for you, go for it. [05:53:36 CEST] <thebombzen> does ffmpeg not work with the new zimg? [05:54:10 CEST] <thebombzen> oh nvm, I'm being dumb [09:36:12 CEST] <martian_> hllo everybody ...I am new to open source and beginner in C and C++ .can someone guide me how can contribute to ffmpeg [10:14:13 CEST] <thebombzen> martian_: http://ffmpeg.org/contributing [10:14:53 CEST] <thebombzen> rip, nvm that's a 404 [10:14:56 CEST] <thebombzen> martian_: https://ffmpeg.org/developer.html [10:17:05 CEST] <martian_> thebombzen:Thank you [18:22:32 CEST] <Pandela> I think there might be a problem with libspeex in FFmpeg [18:22:54 CEST] <Pandela> I can encode a file just fine, but when I use libspeex as a decoder it says No codec could be found with name 'libspeex' [18:22:59 CEST] <Pandela> https://pastebin.com/raw/nZ27Sua4 [18:23:25 CEST] <BtbN> your ffmpeg is built without libspeex then [18:24:17 CEST] <Pandela> BtbN: DEA.L. Speex (decoders: libspeex ) (encoders: libspeex ) [18:24:46 CEST] <BtbN> The output disagrees though [18:25:16 CEST] <BtbN> Are you sure ffplay is as well? [18:26:32 CEST] <Pandela> https://pastebin.com/raw/mFaZ9tmq [18:26:36 CEST] <Pandela> it looks like it might be ffplay [18:28:41 CEST] <BtbN> Yeah, there is no enable-speex in there. [18:29:00 CEST] <BtbN> Can always use ffmpeg itself to play. There is some alsa/pulse output device. [18:29:27 CEST] <Pandela> true, I could try that [18:29:39 CEST] <Pandela> https://pastebin.com/raw/TFvduhMJ yeah it seems to only be ffplay [18:32:59 CEST] <Pandela> https://pastebin.com/raw/WSuGL6RV I wonder if there is any additional flags I can use on the config. Just a curiousity [18:34:14 CEST] <BtbN> How do you even end up with ffplay and ffmpeg from different builds? [18:34:41 CEST] <BtbN> And... why do you even use speex? [18:36:28 CEST] <Pandela> BtbN: what do you mean different builds? :0 [18:36:46 CEST] <Pandela> And I'm experimenting with databending on different codecs lol [18:37:07 CEST] <BtbN> that ffmpeg and ffplay binary are clearly not from the same configure call. [18:37:31 CEST] <Pandela> Oh, I see it now. [18:38:03 CEST] <Pandela> thats weird [18:43:42 CEST] <Pandela> I'll have to look into that [18:44:27 CEST] <Pandela> In the meantime this works: ffmpeg -i input.mp3 -f nut -acodec libspeex -ac 1 - | ffmpeg -f nut -acodec libspeex -ac 1 -i - -f nut -ac 1 - | ffplay -f nut -ac 1 -i - [18:45:24 CEST] <BtbN> you can just do -f alsa default [18:45:35 CEST] <BtbN> and ffmpeg will output to the default alsa device [18:46:16 CEST] <Pandela> ye [18:46:20 CEST] <Pandela> but I wanted to actually decode the data in a pipe so I can replace bytes while its in the pipe [23:40:07 CEST] <selsta> can I use libavformat to get packets from an MPEG-TS stream? something like av_read_frame()? [23:42:02 CEST] <selsta> av_read_frame() returns byte sequences that I cant find in the original file [23:46:42 CEST] <BtbN> of course you can't. It was demuxed. [23:51:08 CEST] <selsta> makes sense [23:52:34 CEST] <selsta> any other way to get the original video and audio stream packets? [23:53:30 CEST] <JEEB> lavg doesn't work on that level, it is supposed to abstract the underlying container from you and giving you the packets for streams that you can then feed to a decoder etc [23:53:45 CEST] <JEEB> if you mean the mpeg-ts packets as-is that is [23:54:02 CEST] <selsta> yes [23:55:46 CEST] <selsta> or maybe it would work if there is a way to tell avformat_find_stream_info() to only read the headers [00:00:00 CEST] --- Mon Aug 28 2017

1 0

ffmpeg-devel.log.20170826
by burek 27 Aug '17

27 Aug '17

[11:32:39 CEST] <cone-766> ffmpeg 03Paul B Mahol 07master:9d6aab6fa160: avfilter/af_surround: make volume configurable for front center and lfe channel [11:43:39 CEST] <cone-766> ffmpeg 03Carl Eugen Hoyos 07master:9d494c5e553f: lavf/rawenc: Add little- and big-endian G.726 muxers. [12:00:28 CEST] <cone-766> ffmpeg 03Carl Eugen Hoyos 07master:1c56becb9b04: lavc/utils: Calculate frame duration for little-endian G.726. [12:50:35 CEST] <cone-766> ffmpeg 03Carl Eugen Hoyos 07master:094d4d8691ab: lavc/sinewin_tablegen: Fix compilation with --enable-hardcoded-tables. [15:19:59 CEST] <cone-766> ffmpeg 03Paul B Mahol 07master:473e18fdbabb: doc/filters: improve pseudocolor example [16:59:13 CEST] <BBB> j-b: ping [18:10:55 CEST] <durandal_1707> Compn: why not announce that mplayer is officially dead [18:12:20 CEST] <JEEB> it's a hobby project, it will never die [18:12:27 CEST] <JEEB> as long as it's someone's hobby [18:13:03 CEST] <Compn> it still works [18:13:29 CEST] <Compn> and this way it never gets more bloated, unlike vlc :) [18:13:31 CEST] <durandal_1707> it doesnt it stinks [18:13:40 CEST] <Compn> what problems you having now ? :D [18:14:21 CEST] <durandal_1707> Compn: problems is people still use mplayer crap [18:14:57 CEST] <Compn> hmm yes [18:15:01 CEST] <Compn> i dont want new users using it [21:26:24 CEST] <cone-247> ffmpeg 03Paul B Mahol 07master:15e9c4afdc8e: avfilter/af_amix: switch to activate [21:26:24 CEST] <cone-247> ffmpeg 03Paul B Mahol 07master:7f5c655833c5: avfilter/af_amix: simplify const entries for duration in amix_options[] [22:08:11 CEST] <graphitemaster> How exactly do things like mpv/mplayer handle software only decoding of videos so well with the libavcodec, yet when I try and do all the same things (avoid software scaling/filter, multi thread processing of frames, etc) performance is absymal. I don't understand how one uses libavcodec well enough to get good performance out of it. We can only really use the software side of it since we're manipulating the raw YCbCr stuff, [22:08:11 CEST] <graphitemaster> and using that as a texture in a 3D scene, plus the hwaccel stuff is very much a complete utter mess of conflated choices about OS/hardware [22:10:55 CEST] <graphitemaster> I can launch four instance of mpv with --hwdec=no playing 4k h.264 videos and my CPU utilization is like 20%, yet I do the same thing with my code I'm hitting 400% cpu usage and it's literally all spent in avcodec_decode_video2 [22:28:25 CEST] <JEEB> graphitemaster: did you happen to do something stupid like disabling yasm? [22:28:57 CEST] <JEEB> graphitemaster: unless you're doing something really dumb you shouldn't be much slower than `ffmpeg -i stuff -f null -` [22:29:43 CEST] <graphitemaster> JEEB, we build ffmpeg from source on Linux (for which we use the default configure flags), on Windows we use Zerano's builds (which presumably are optimized) [22:29:49 CEST] <graphitemaster> both are slow [22:30:11 CEST] <graphitemaster> yasm is installed on my development rig, so I would assume ffmpeg configure would use it [22:30:16 CEST] <JEEB> it should [22:30:56 CEST] <JEEB> test with the ffmpeg command line app, and compare speeds. I have written some really dumb code and I'm seeing similar performance [22:33:42 CEST] <graphitemaster> yeah, the command line is running faster :( [22:37:05 CEST] <graphitemaster> am I just using avcodec wrong, I search for suitable decoders for all streams with avcodec_find_decoder, copy the codec context, and call avcodec_open2, setup some temporary scratch storage space for frames for each stream and on a separate thread I consume frames with avcodec_read_frame, shoving them into a buffer, which is then processed +- some syncronization code and switches on the frame types and does what needs to be [22:37:05 CEST] <graphitemaster> done [22:38:09 CEST] <graphitemaster> and all the time is spent in avcodec_decode_video2 (well a good 80 to 90% is for 4k video) [22:39:06 CEST] <graphitemaster> I do sit in a while loop for when the packet size is > 0, doign decode_video2, subtracting off that length since that's a thing *shrug* [22:39:14 CEST] <graphitemaster> and yeah if the length < 0 I just break from that loop [22:39:20 CEST] <graphitemaster> so no weird contention there [22:39:38 CEST] <JEEB> I recommend you take a look at the decoding examples and utilize the new API with reference counting enabled [22:40:07 CEST] <graphitemaster> this would be the _third_ time I've had to rewrite our code because yall apis keep changing and deprecating :P [22:40:08 CEST] <JEEB> but in general if you are doing just decoding, it shouldn't be much slower than ffmpeg.c [22:40:18 CEST] <wm4> graphitemaster: what frame scratch space? [22:40:26 CEST] <JEEB> the push/pull thing is not exactly new [22:40:47 CEST] <wm4> also copying codec contexts hints you're using another deprecated APIs [22:40:51 CEST] <graphitemaster> wm4, space for the second argument to avcodec_decode_video2, the AVFrame [22:41:22 CEST] <JEEB> anyways, the only reason I commented is because mpv et al utilize the push/pull APIs and refcounted AVFrames [22:41:31 CEST] <wm4> also did you set threads [22:41:36 CEST] <graphitemaster> set threads? [22:41:47 CEST] <JEEB> isn't that enabled by default for many decoders that support threading? [22:41:51 CEST] <wm4> AVCodecContext.thread_count or something [22:42:02 CEST] <wm4> JEEB: not in the API, AFAIK [22:42:04 CEST] <JEEB> oh [22:42:17 CEST] <graphitemaster> the meat of my video packet handling code: https://pastebin.com/raw/ih4dqeYQ [22:42:17 CEST] <JEEB> then I'm even more impressed my code was as fast as it was [22:42:50 CEST] <wm4> you call swscale... [22:42:56 CEST] <wm4> speed -> ruined [22:42:59 CEST] <graphitemaster> only if video_resampling [22:43:03 CEST] <graphitemaster> which I have disabled by default [22:43:20 CEST] <graphitemaster> that is only used when the video is not already in ycbcr format [22:43:25 CEST] <wm4> then maybe your funny cMediaVideoPacket stuff [22:43:53 CEST] <graphitemaster> going to try and set the thread_count thing [22:43:56 CEST] <graphitemaster> if I can find that field lol [22:43:59 CEST] <wm4> do you use AVPacket correctly? [22:45:44 CEST] <graphitemaster> I hope I do [22:45:56 CEST] <graphitemaster> the actual decode thread stuff https://pastebin.com/raw/kpM9Bbpb [22:47:53 CEST] <wm4> why the fuck is there a sleep call [22:48:17 CEST] <graphitemaster> I've commented those out, does not affect performance in any way shape or form [22:48:29 CEST] <graphitemaster> prolly because those functions don't even do anything if the sleep is < 100ms so [22:48:35 CEST] <graphitemaster> don't know who put those in there [22:49:29 CEST] <wm4> let me guess, it's game code [22:56:52 CEST] <graphitemaster> wm4, nope actually [22:56:56 CEST] <graphitemaster> engine code though :P [22:57:24 CEST] <BBB> and the profile? [22:57:37 CEST] <BBB> like, youre saying its slow and all time is spent in avcodec_decode_video2 [22:57:43 CEST] <BBB> wheres the profile? [22:58:22 CEST] <graphitemaster> we use sampler profiler called Remotery, sadly I can't get you much out of that other than a screenshot of it's output in a webbrowser [22:58:35 CEST] <BBB> go for it [23:00:35 CEST] <graphitemaster> http://i.imgur.com/cTWGSAJ.png [23:01:11 CEST] <BBB> I mean a profile, like % runtime spent in each function [23:01:14 CEST] <graphitemaster> that decode, if you look at the code is a scoped profile region around the call [23:01:51 CEST] <BBB> like http://blog.fellstat.com/wp-content/uploads/2013/04/InstrumentsScreenSnapz0… [23:02:21 CEST] <graphitemaster> those values are in microseconds per frame [23:02:32 CEST] <graphitemaster> so it's taking 17.394 milliseconds in that call [23:02:47 CEST] <BBB> you have 5 ms in a Create function [23:02:56 CEST] <BBB> are you calling mallocs and creating objects in there? [23:03:14 CEST] <graphitemaster> yes :| [23:03:19 CEST] <BBB> anyway, a profile needs more granularity than this [23:03:19 CEST] <graphitemaster> cutting off that 5ms would help a lot [23:03:33 CEST] <BBB> I cant say whether the time spent in Handle() is spent in avcodec_decode_video2() or not [23:03:40 CEST] <BBB> a good profiler tells you that [23:03:45 CEST] <graphitemaster> the "[DECODE]" is all avcodec [23:03:51 CEST] <graphitemaster> ProfileCPU( "cMediaVideoPacket::Handle [Decode]" ) [23:03:51 CEST] <graphitemaster> { [23:03:51 CEST] <graphitemaster> nLength = avcodec_decode_video2( pVideoCodecContext, [23:03:51 CEST] <graphitemaster> (AVFrame *)pMedia->m_pScratchVideoFrame, [23:03:51 CEST] <graphitemaster> &nFrameFinished, [23:03:53 CEST] <graphitemaster> pPacket ); [23:03:54 CEST] <graphitemaster> } [23:04:05 CEST] <graphitemaster> that ProfileCPU region counts that call and that call only [23:04:16 CEST] <graphitemaster> it's a C++ object that goes out of scope at the } [23:04:28 CEST] <graphitemaster> so the ctor/dtor times that region of code [23:05:05 CEST] <BBB> ok [23:05:06 CEST] <BBB> so [23:05:08 CEST] <graphitemaster> 17349 microseconds are spent on avcodec_decode_video2, 5350 miroseconds in that create, for a total of 22704 microseconds (or 22 milliseconds for that frame in total) [23:05:25 CEST] <BBB> I think you need to learn about profiling a little bit more, sorry [23:05:40 CEST] <BBB> I dont know how this ProfileCPU thing works [23:05:54 CEST] <BBB> but a good profiler tells me total runtime, time spent in _all_ (not some, annotated) functions [23:05:56 CEST] <BBB> etc. [23:06:02 CEST] <BBB> without that, I cant tell you why its slow [23:06:08 CEST] <graphitemaster> yeah, this doesn't go that deep :| [23:06:13 CEST] <graphitemaster> it can only time stuff I annotate [23:06:14 CEST] <BBB> it could be the locking, the Create, the Write [23:06:22 CEST] <BBB> on a mac, use isntruments [23:06:25 CEST] <BBB> instruments* [23:06:30 CEST] <graphitemaster> I would have to actually dig in deeper with gprof [23:06:41 CEST] <graphitemaster> or valgrind's cachegrind *shudder* [23:06:42 CEST] <BBB> on linux, use perf [23:06:52 CEST] <BBB> perf should be ok, try perf [23:06:59 CEST] <BBB> Ive used it, its good enough [23:07:38 CEST] <graphitemaster> I'd have to recompile ffmpeg with debug/perf instrumentation first, and setup a test senario that launches directly into video decoding first just to reduce the noise and nonsense to get there [23:07:42 CEST] <graphitemaster> but yeah I should. [23:08:15 CEST] <BBB> how do you think we get ffmpeg so far? its not by annotating functions one-by-one ;) [23:08:25 CEST] <BBB> its by using great tools that tells us exactly what to optimize etc. [23:08:42 CEST] <BBB> (instead of us asking one-by-one should I optimize this? should I optimize that?) [23:09:41 CEST] <graphitemaster> sadly, in my industry, the common ways of timing stuff (since everything is in the context of a frame) is to manually put these annotated blocks of shit around shit and depending on how much annotation you do, the more coarse it can get [23:10:16 CEST] <BBB> Make SoftwareEngineering Great Again! [23:10:52 CEST] <graphitemaster> it's not without it's own set of problems, but it works great for getting an overall picture of stuff, plus most instrumentation based profilers (like perf) ruin the performance of things that it takes hours to even get to the part we want to test that is slow (things like cachegrind for instance, run our stuff 400 to 2000x slower than native) [23:11:16 CEST] <graphitemaster> you could probably simulate a cache or cpu in your head faster heh [23:13:09 CEST] <wm4> perf doesn't need instrumentation [23:16:37 CEST] <graphitemaster> thanks arch [23:16:38 CEST] <graphitemaster> CONFIG_AUDIT is disabled in the Arch kernel packages so a custom kernel [23:16:38 CEST] <graphitemaster> is required for most components of this package. However, some features [23:16:39 CEST] <graphitemaster> like the utility methods in libaudit work without kernel support. [23:16:49 CEST] <graphitemaster> perf is gimped as hell with Arch kernels apparently [23:16:57 CEST] <graphitemaster> don't feel like building a kernel right now [23:19:03 CEST] <BBB> is 22 ms the first frame? [23:19:11 CEST] <BBB> or average over all frames? [23:19:28 CEST] <wm4> anyway, as long as you set the thread count, and your AVPacket data is aligned and padded with 0s, all should be fine [23:19:40 CEST] <BBB> set thread count to 0 [23:19:43 CEST] <BBB> so it auto-detects threading [23:19:57 CEST] <BBB> is that not the default yet? [23:20:04 CEST] <wm4> no idea [23:20:13 CEST] <wm4> I think it's not [23:20:30 CEST] <wm4> and do it _before_ opening the codec [23:21:00 CEST] <graphitemaster> maybe I should just use mpv's libmpv. it seems to have an opengl api that gives me a GLuint handle and supports hwacceleration too [23:21:05 CEST] <graphitemaster> and scrap all this garbage [23:21:25 CEST] <graphitemaster> wm4, have an example of how to use libmpv ? [23:21:44 CEST] <wm4> graphitemaster: there's a mpv-examples repo [23:26:12 CEST] <graphitemaster> wm4, OpenGL ES support too GLES3 similar to desktop GL 3.x core profile (supports PBOs and what not, very little changes of code needed) [23:26:23 CEST] <graphitemaster> if not I'll add it myself if need be [23:26:39 CEST] <graphitemaster> if this turns out to be way better for performance that is ;-) [23:27:16 CEST] <wm4> not sure what you're asking... it supports OpenGL desktop 2.1 and ES 2.0 [23:28:22 CEST] <graphitemaster> yeah but will it work with a higher context, i.e some functionality is deprecated and if you use it with my non compatible context, it'll fail [23:28:44 CEST] <graphitemaster> since we don't create compatability context for performance reasons, only core profile contexts [23:31:11 CEST] <wm4> mpv CLI normally creates a GL 4.3 core context [23:31:21 CEST] <wm4> there shouldn't be any compatibility crap in use [23:31:39 CEST] <wm4> btw. we're also working on Vulkan support, and our worst problem is finding a GLSL compiler [23:35:27 CEST] <graphitemaster> glsl-lang is fine [23:35:40 CEST] <graphitemaster> most people just be integrating that into the thing [23:35:49 CEST] <graphitemaster> or offline compiling the shaders and plopping their bytecode into stuff [23:37:13 CEST] <wm4> you mean the khronos lib? it has global mutable state, a C++ only API (and a broken and unmaintained C one), and apparently leaks memory [23:37:24 CEST] <wm4> we need a lib [23:37:31 CEST] <wm4> because we compile shaders on the fly [23:58:11 CEST] <J_Darnley> graphitemaster: perf should work okay on Arch for your user space code, it does for me using their kernel. [23:58:36 CEST] <graphitemaster> wm4, that is an unsolved problem right now [23:58:49 CEST] <graphitemaster> wm4, apparently LunarG has such a compiler but won't make it open source [23:59:09 CEST] <J_Darnley> I know nothing of the nernel but I assume CONFIG_AUDIT lets you profile kernel code. [23:59:40 CEST] <graphitemaster> J_Darnley, I tried it, i get some perf data but when I go to annotate it it says no samples :| [23:59:45 CEST] <graphitemaster> so I assume that I do need that? [00:00:00 CEST] --- Sun Aug 27 2017

1 0

ffmpeg.log.20170826
by burek 27 Aug '17

27 Aug '17

[01:43:49 CEST] <wiak> for some reason my relay rtmp ffmpeg stream has audio out of sync [01:44:10 CEST] <wiak> https://gist.githubusercontent.com/nwgat/82d069feb75be7d0e4ec7de71cd8c263/r… [01:44:18 CEST] <wiak> there is the cli [01:44:57 CEST] <wiak> am using obs studio 20 as souce [01:55:28 CEST] <furq> you should probably use a real rtmp server as a relay [01:55:52 CEST] <furq> i've not really used ffmpeg's -listen stuff but based on how few people seem to use it, i expect it's not very good [01:56:19 CEST] <furq> you can exec ffmpeg to do the reencoding from nginx-rtmp [02:05:39 CEST] <leeaandrob> hello [02:16:33 CEST] <ThugAim> herro [02:17:20 CEST] <leeaandrob> :) [03:12:37 CEST] <noop__> Hi everyone! is there any C code available that demonstrates how to convert AV_PIX_FMT_YUV420P to AV_PIX_FMT_RGB24? [03:13:15 CEST] <noop__> I have written some code, but it writes junk to the last two columns of every frame [03:13:45 CEST] <DHE> libswscale I think... or you can use libavfilter and have it do the heavy lifting [03:16:33 CEST] <JCount_> Can anyone provide some advice on how to report a build related regression? In this case, configuring with --enable-hardcoded-tables causes the build to fail with a linker error: 'ld: symbol(s) not found for architecture x86_64'. [03:18:28 CEST] <noop__> thanks! I'm already using libswscale (sws_getContext, then av_read_frame, avcoded_send_packet, avcodec_receive_frame and then then sws_scale) [03:22:57 CEST] <JCount_> The relevant patch is http://ffmpeg.org/pipermail/ffmpeg-devel/2017-August/215104.html or commit dbc9a8f21f92d0613142ea23bb836356fc41de38 in master. [05:36:24 CEST] <wiak> furq seem to work better hehe, that nginx-rtmp, tried it before but it seems i had to push the stream to get it to work ;P [05:36:42 CEST] <wiak> furq https://www.smashcast.tv/nwgat [05:36:43 CEST] <wiak> ) [18:40:34 CEST] <blerrp> regarding mp3 id3 metadata: do you know if proper comment tag (id3 frame COMM) is supported? doing `ffmpeg -metadata 'comment=foobar'` seems to write a TXXX frame with description=comment, and this is not readable as a comment by many/most common mp3 players [18:41:36 CEST] <ChocolateArmpits> Can ffmpeg potentially stall if input timestamp is lower than the previous timestamp ? [18:43:02 CEST] <azarus> How can I enable the x11grab device? [18:43:13 CEST] <JEEB> ChocolateArmpits: the only thing that could put things to sleep() is the -re mode which in general you shouldn't be using [18:43:31 CEST] <JEEB> otherwise, no. it shouldn't stall but more likely throw an error if the timestamps go backwards [18:47:42 CEST] <ChocolateArmpits> What about timestamps that go excessively forward, would -re cause blank frames to be rendered to account for the output time? [18:48:31 CEST] <JEEB> no, -re would just wait until that timestamp, which is why you shouldn't trust -re at all [18:49:01 CEST] <JEEB> because if you get a timestamp funkiness in there, it will do weird-ass things [18:59:47 CEST] <zarac> azarus: got it working ok (x11grab)? [19:08:30 CEST] <zarac> azarus: I went through the same thing yesterday. I made a little script that helps starting the recording. https://gist.github.com/zarac/42e76ac8c78ebeb7a69ed410fa3070c0 [19:09:37 CEST] <zarac> azarus: It's quite simple to use.. and the code kinda explains it. It has a nifty feature that helps you resizing the window (using wmctrl). [19:11:37 CEST] <zarac> There is however a issue with the last part of the audio getting cut off... but perhaps you dont' have this issue.. it seems to be a bug using pulse (maybe you can use alsa instead). [19:15:37 CEST] <zarac> (btw, a ffmpeg bug, not in that ffrecord... just to be clear) : ) [19:53:46 CEST] <Pandela> Morning peoples [19:54:04 CEST] <Pandela> Does anyone know a way to compile FFmpeg in windows 7 with ladspa support? [19:54:55 CEST] <durandal_1707> Pandela: just get header installed in right spot [19:55:40 CEST] <durandal_1707> btw which ladspa plugin you want to use? [19:56:22 CEST] <Pandela> durandal_1707: Stuff like cmt, swh and other libraries [19:57:30 CEST] <durandal_1707> Pandela: if you use mingw64 msys2 project it should be easy to compile ffmpeg [19:58:31 CEST] <Pandela> Thanks! [19:58:32 CEST] <Pandela> durandal_1707: Do you have any clues how I would go about the Ladspa header in windows? I have only compiled FFmpeg in linux personally [19:59:14 CEST] <durandal_1707> with mingw64 just install header with pacmam [19:59:25 CEST] <durandal_1707> *pacman [20:06:39 CEST] <Pandela> Back, internet died lol [20:07:07 CEST] <Pandela> durandal_1707: But yeah let me try that out, thanks for the tip c: [00:00:00 CEST] --- Sun Aug 27 2017

1 0