Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

August 2017

1 participants
62 discussions

ffmpeg-devel.log.20170815
by burek 16 Aug '17

16 Aug '17

[00:51:34 CEST] <rcombs> remind me why the data arg is void* instead of AVFrame* [00:52:18 CEST] <rcombs> also isn't that changed with the new API anyway [01:13:16 CEST] <atomnuker> rcombs: I'll answer if you push your patches [01:15:45 CEST] <rcombs> is everyone okay with how they fuck up the MD5 [01:16:27 CEST] <rcombs> or, well, can, if you trim in a remux [01:16:37 CEST] <rcombs> dunno if that's really solvable [01:16:56 CEST] <atomnuker> md5? [01:17:08 CEST] <atomnuker> I just want the one to mux in coverart [01:21:10 CEST] <J_Darnley> No, no! Flac files do not have video streams! [01:25:24 CEST] <rcombs> oh boy, an objection [01:25:28 CEST] <rcombs> of some sort [01:29:10 CEST] <J_Darnley> Not to your patches but rather to how ffmpeg treats these binary data attachments. [01:30:31 CEST] <cone-352> ffmpeg 03Michael Niedermayer 07master:426a322aa2bf: avcodec/cavsdec: Check I frame mb decode for errors [01:30:31 CEST] <cone-352> ffmpeg 03Michael Niedermayer 07master:b9ce43625c43: avcodec/cavsdec: Check P/B frame mb decode which return error codes [01:38:41 CEST] <rcombs> oh yeah, that's kinda weird [01:38:45 CEST] <rcombs> but it's how it works so w/e [03:08:08 CEST] <atomnuker> michaelni: there's something wrong with swr I think [03:08:45 CEST] <atomnuker> lets say I have a huge buffer of say 13230000 samples I want to resample from 44100 to 48000 hz [03:09:41 CEST] <atomnuker> and I give it to swr directly and ask for a small amount of samples back, e.g. swr_convert(swr, out, 1024, in, 13230000) [03:09:58 CEST] <atomnuker> (and of course the number of samples resampled is returned) [03:10:59 CEST] <atomnuker> if I do this until swr_convert returns 0 I get a total of 21216000 samples back [03:11:28 CEST] <atomnuker> which at 48000 hz is 442 seconds [03:11:48 CEST] <atomnuker> but the 13230000 samples I fed in at 44100 are exactly 300 seconds [03:12:08 CEST] <atomnuker> so swr returned an extra 142 seconds of audio [03:13:29 CEST] <atomnuker> up until 300 seconds its all fine, then what's resampled is 142 seconds of reversed audio starting from the end [03:14:09 CEST] <atomnuker> what the fuck is going on? [03:15:08 CEST] <atomnuker> if I feed in swr say 4096 samples at a time the amount of extra samples at the end gets reduced [03:16:00 CEST] <atomnuker> and if I reduce that to 1800ish samples I get almost a correct time [03:25:55 CEST] <michaelni> atomnuker, is this a regression ? and how can this be reproduced ? ... would be ideal if we had a fate test to test such things [03:26:12 CEST] <atomnuker> no idea if its a regression [03:26:25 CEST] <atomnuker> it has been this way since May [03:26:36 CEST] <atomnuker> (when I first used it) [03:56:48 CEST] <atomnuker> michaelni: https://pars.ee/temp/resample_fail.c [03:57:18 CEST] <atomnuker> compile with gcc example.c $(pkg-config --libs libavcodec) [03:58:15 CEST] <atomnuker> put some audio in the buffer and fwrite it, you'll hear the same as what I hear [04:00:28 CEST] <atomnuker> change const int samples_avail = FFMIN(1800, samples_left); and you'll see it'll be a few thousands longer instead of several hundred seconds [04:03:18 CEST] <atomnuker> (I guess it could be made into a fate test but its no point testing something that seems to be broken) [04:13:46 CEST] <michaelni> will take a look when i have time, unless someone else does before [15:05:33 CEST] <cone-544> ffmpeg 03Paul B Mahol 07master:8d2da0939cbd: avfilter/vf_datascope: make it possible to change pixscope window position [15:52:58 CEST] <cone-544> ffmpeg 03Vittorio Giovara 07master:14604087031d: Add single precision planar RGB pixel formats [15:52:59 CEST] <cone-544> ffmpeg 03Vittorio Giovara 07master:8b9ae9a8e03c: zscale: Enable single precision input/ouput filtering [15:53:00 CEST] <cone-544> ffmpeg 03Vittorio Giovara 07master:62dfa2ba14d9: Add tonemap filter [17:25:09 CEST] <J_Darnley> In a decoder what do I put into the "void *data" argument, and when? [17:25:15 CEST] <J_Darnley> How do I tell it where the AVFrame is I want to output is when it is ready? [17:25:50 CEST] <J_Darnley> Do I need to set something other than got_frame to 0 or NULL when I am not outputting anything? [17:27:01 CEST] <atomnuker> *data always points to an avframe, it just lacks allocated buffers [17:27:46 CEST] <atomnuker> if you have a frame set *got_frame to 1 and alloc/transfer buffers onto the *data avframe [17:29:40 CEST] <J_Darnley> Do I just copy/assign the contents of my AVFrame struct into the address data points to then? [17:30:07 CEST] <atomnuker> you have an internal avframe, right? [17:30:13 CEST] <J_Darnley> I do now. [17:30:47 CEST] <atomnuker> then do av_frame_ref(data, internal_av_frame) [17:30:53 CEST] <J_Darnley> Yes, I leave data untouched. [17:31:09 CEST] <J_Darnley> okay, I will try that. [17:33:27 CEST] <J_Darnley> Colour me surprised. [17:33:41 CEST] <J_Darnley> That seems to work. [17:34:09 CEST] <J_Darnley> Now we're back to 1 frame of decoding, kierank. [17:34:36 CEST] <kierank> atomnuker: why av_frame_ref? [17:34:50 CEST] <kierank> surely that leaves a reference with the internal frame as well [17:34:55 CEST] <kierank> this is confusing me quite a bit [17:35:46 CEST] <kierank> J_Darnley: I think we want av_frame_move_ref [17:36:16 CEST] <J_Darnley> coming right up. [17:37:20 CEST] <atomnuker> kierank: hm, you're right [17:37:33 CEST] <atomnuker> (since the internal avframe is reused) [17:38:09 CEST] <atomnuker> so if you wanted to decode more than 1 frame and do nothing the first one would be junk [17:40:04 CEST] <J_Darnley> Better, 20 frames output with move_ref [17:40:58 CEST] <J_Darnley> Runnign valgrind [17:42:18 CEST] <atomnuker> michaelni: does the swresample patch fix the issue I had? [17:43:15 CEST] <J_Darnley> Valgrind looks good. [17:43:28 CEST] <J_Darnley> Do you want the diff, kierank? [17:43:40 CEST] <kierank> can you send me a git-format path [17:43:43 CEST] <kierank> patch [17:44:32 CEST] <J_Darnley> Do you want me to cram it all into one collosal patch? Not I think there are any changes I could separate. [17:45:11 CEST] <kierank> yes [17:45:47 CEST] <J_Darnley> Okay. I will leave out the printfs though. [18:02:28 CEST] <kierank> lol [18:02:29 CEST] <kierank> I came across your website ffmpeg.org and you would be good fit to our program focused on international oriented startups and scale-ups that can provide added value for media companies in the areas of content, advertising or technology. Dutch media organizations are actively looking for companies like you. [18:12:58 CEST] Action: J_Darnley feels left out of the spam party [19:31:09 CEST] <durandal_1707> im out of ideas for new filters [19:31:27 CEST] <atomnuker> durandal_1707: write simd? [19:31:56 CEST] <atomnuker> (transpose is slow and doesn't have simd, but at least it does slice threading) [19:35:20 CEST] <durandal_1707> how would you transpose simd? [19:36:10 CEST] <BtbN> the color/chromakey filters could also use some work [19:36:43 CEST] <BtbN> They are very simplistic and slow. Made them in the hopes for there to be enough interest to get them improved, but so far that didn't happen [19:37:05 CEST] <atomnuker> durandal_1707: lookup tables [19:38:07 CEST] <J_Darnley> durandal_1707: have a holiday [19:38:12 CEST] <durandal_1707> atomnuker: that doesnt makes sense? [19:39:36 CEST] <atomnuker> durandal_1707: you're right, it doesn't, transpose only has moves, no multiplies [19:41:06 CEST] <durandal_1707> vs have simd, but there is no nice way to bench it [19:43:12 CEST] <J_Darnley> if you're desperate for something to do you could finish that differencemax mode I proposed for overlay or blend [19:50:27 CEST] <kierank> durandal_1707: lipsynctest filter with correct 1601 NTSC support ;) [19:56:40 CEST] <durandal_1707> kierank: what? [19:57:21 CEST] <kierank> Filter to generate lipsync test but working correctly with ntsc [19:57:27 CEST] <kierank> So 1601, 1602 pattern [21:51:34 CEST] <michaelni> atomnuker, it should fix the issue you reported yesterday [22:32:18 CEST] <durandal_1707> atomnuker: posted patch that speeds up transpose filter [22:37:36 CEST] <atomnuker> durandal_1707: lgtm'd [22:37:40 CEST] <atomnuker> michaelni: I'll test it now [22:46:02 CEST] <atomnuker> michaelni: patch lgtm'd, tested and works, thanks alot [23:15:15 CEST] <durandal_1707> why are compilers shit? [23:16:19 CEST] <durandal_1707> i created inline function of 2 hardcoded parameters that are used in loops and speed was raised with inlined function [23:16:57 CEST] <durandal_1707> its just hardcoding w and h [23:17:43 CEST] <TD-Linux> look at the assembly [23:18:20 CEST] <durandal_1707> why its just hardcoded loop number [23:18:52 CEST] <TD-Linux> you're comparing hard coding and not hard coding? [23:19:03 CEST] <durandal_1707> and compiler is instructed to not add own simd code [23:19:20 CEST] <durandal_1707> TD-Linux: just loop numbers [23:20:17 CEST] <TD-Linux> it can still copy larger chunks at once (and potentially unroll without lead in/out). look at the assembly [23:21:23 CEST] <atomnuker> even with tree vectorization off gcc still vectorized some simple shifts + movs double loops [00:00:00 CEST] --- Wed Aug 16 2017

1 0

ffmpeg.log.20170815
by burek 16 Aug '17

16 Aug '17

[00:00:48 CEST] <SpLiC3> I should note when accessing the resulting remuxed .ts over http vlc handles it ok with a 4 sec or so delay, the first video frame shows then it buffers? or waits for x new packets? [05:44:17 CEST] <willbarksdale> Hey folks, I am currently decoding an RTMP stream over a wifi network using FFMPEG, I would like to also send this FTMP stream to the facebook live API. Is it possible to somehow send the stream directly to fb live without decoding it? I am trying to avoid decoding and re-encoding at the same time. [05:51:11 CEST] <willbarksdale> I am using FFMpeg on iOS [06:17:49 CEST] <Cracki_> stream copy [06:18:04 CEST] <Cracki_> meaning -c copy [12:48:56 CEST] <Eldarko> Hello, guys! Is it possible to send segments with meta-data (such as duration/time) via http? Lets say, i want to send .ts files from my home to server, store em there, and then build a playlist on a server-side. [12:49:20 CEST] <BtbN> HLS [12:52:35 CEST] <Eldarko> HLS is for the playlist. Playlist requires at least a duration and filename. How do i send this data via http by ffmpeg with each segment? [12:57:41 CEST] <BtbN> it writes that to the playlist automatically if you use the hls muxer [12:57:48 CEST] <BtbN> just need to run a HTTP server to serve it [13:00:35 CEST] <Eldarko> can it send me duration as http header, or something like that? [13:00:52 CEST] <BtbN> The duration is in the playlist [13:01:19 CEST] <BtbN> HTTP servers usually don't parse media file to extract metadata [13:03:11 CEST] <Eldarko> Yeah, well, ill have to parse each ffmpeg playlist in order to get duration of the segment. I was hoping there is a way to get it w/o parsing the string [13:05:56 CEST] <Eldarko> i dont really need this playlist, i only need a .ts file itself and its duration since its too expensive to extract it later from .ts file. [13:09:43 CEST] <Eldarko> Thak you, Timo ) [14:41:32 CEST] <erika> hi! quick question for devs: is there any plan for basic support of dolby AC4? [14:42:01 CEST] <erika> lmk if it's better suited for #ffmpeg-devel [14:42:34 CEST] <BtbN> if you manage to find a spec that's not tied to some NDA or crazy license fees, and someone willig to implement it. [14:43:17 CEST] <furq> does anything actually use ac4 [14:43:41 CEST] <furq> now, i mean [14:43:44 CEST] <furq> i'm sure it's only a matter of time [14:44:03 CEST] <dystopia_> is dolby atmos ac4? [14:44:23 CEST] <furq> no [14:44:29 CEST] <erika> hmmm OK, thanks - not in the near future then [14:45:06 CEST] <furq> ATSC 3.0 supports Dolby AC-4 and MPEG-H 3D Audio. [14:45:08 CEST] <furq> oh wonderful [14:45:36 CEST] <dystopia_> i live in dvb land [14:45:44 CEST] <furq> same [14:45:48 CEST] <dystopia_> things here are moving to aac [14:47:01 CEST] <furq> yeah dvb-t2 is exactly the same as dvb-t as far as audio goes [14:50:57 CEST] <furq> Currently a Dolby Digital 5.1-channel soundtrack can be encoded with AC-3 using 384Kbps but with AC-4 that same track can be encoded at only 96Kbps with no perceivable loss in quality. In fact the compression is so good that a stereo track can be encoded at just 32Kbps, [14:51:01 CEST] <furq> what [14:51:17 CEST] <furq> "can be" is doing a lot of work in that sentence [14:52:38 CEST] <cryptodechange> Is a network drive output for ffmpeg a bad idea? [14:52:50 CEST] <cryptodechange> Could the end result be corrupted, local network [14:52:56 CEST] <furq> do you plan on outputting at more than 1gbps [14:53:13 CEST] <BtbN> if it's not seekable, you're in for half-broken or entirely broken stuff [14:53:36 CEST] <cryptodechange> It's pretty much locally connected via. a switch, literally just compressing video sources [14:53:44 CEST] <cryptodechange> but in the event of hanging, packet loss, etc [14:53:51 CEST] <BtbN> Using NFS is perfectly fine [14:53:56 CEST] <BtbN> if it's on a LAN [14:53:58 CEST] <furq> right [14:54:09 CEST] <BtbN> that's why TCP exists [14:54:10 CEST] <furq> obviously don't do that shit to sshfs over wan, but cifs/nfs on a lan will be fine [14:54:22 CEST] <furq> packet loss won't be an issue unless you pull a cable [14:54:49 CEST] <cryptodechange> Using an SMB share which I mounted [14:54:53 CEST] <furq> smb is cifs [14:56:40 CEST] <cryptodechange> Ok sure, but is there a slight off chance of packet loss (faulty cable, congestion, over worked drives), will FFMPEG wait until data is written? [14:57:02 CEST] <BtbN> ffmpeg has no idea and doesn't care about the network part of it [14:57:09 CEST] <BtbN> it just sees a local file [14:57:32 CEST] <furq> right [14:57:33 CEST] <cryptodechange> Say I am scrubbing my ZFS drive, whilst xfering a lot of data, and operations are waiting/hanging on the data [14:57:53 CEST] <cryptodechange> ok interesting [14:58:14 CEST] <furq> this is why we have buffers [14:58:16 CEST] <cryptodechange> Is there any way to check for corrupted/bad frames, instead of using my eyes? :P [14:58:44 CEST] <BtbN> what kind of hellish network are you on that you expect it to mangle everything that goes through it? [14:58:53 CEST] <furq> ffmpeg -v quiet -xerror -i foo.mp4 -f null - || echo oh no!! [15:00:17 CEST] <cryptodechange> \o/ [15:01:23 CEST] <cryptodechange> This is my setup [15:01:24 CEST] <cryptodechange> https://imgur.com/a/6Bjxh [15:01:39 CEST] <cryptodechange> Behemoth is my 48 TB NAS and plex server [15:01:52 CEST] <cryptodechange> Little box is my seedbox/encode destination [15:02:02 CEST] <cryptodechange> So: big nas - encode > little nas - rsync > big nas [15:02:16 CEST] <cryptodechange> My line of thinking was to avoid fragmentation over long encode times, when other stuff is being xfered [15:02:25 CEST] <cryptodechange> As ZFS can't be defragged in a traditional sense [15:07:38 CEST] <BtbN> you're worrying about all the wrong things... [15:07:56 CEST] <BtbN> Networks don't shred data passing through it, and modern file-systems have no need to worry about fragmentation [15:09:22 CEST] <furq> nah zfs fragmentation is a pain [15:09:36 CEST] <viric> btrfs fragmentation too [15:09:37 CEST] <furq> i doubt that this is going to help matters though [15:10:27 CEST] <furq> also i hope you budgeted 20% of that 48TB for leaving empty forever or else the zpool performance goes to absolute fucking shit [15:10:42 CEST] <viric> :) [15:10:43 CEST] <furq> because you'll need to do that [15:34:39 CEST] <cryptodechange> It's 12 * 6TB, split into 2 raidz-2 vdevs [15:43:56 CEST] <furq> that seems like an excessively large raid6 [15:58:38 CEST] <SoreGums> how do i get these 2 commands into a single command? I know i need to use filter complex however all combinations I've tried don't work. What I want is to downmix the 6ch opus to aac and have both 6ch & 2ch in the mkv [15:58:42 CEST] <SoreGums> ffmpeg -i chapters.video.audio-6ch-opus.subtitles.mkv -map_metadata -1 -map_chapters -1 -vn -sn -c:a aac -af "pan=stereo|FL < 1.0*FL + 0.707*FC + 0.707*BL|FR < 1.0*FR + 0.707*FC + 0.707*BR" audio-2ch-aac.m4a [15:58:42 CEST] <SoreGums> ffmpeg -probesize 150M -analyzeduration 150M -i audio-2ch-aac.m4a -i chapters.video.audio-6ch-opus.subtitles.mkv -map 0 -map 1 -c copy chapters.video.audio-6ch-opus.audio-2ch-aac.subtitles.mkv [16:01:46 CEST] <SoreGums> as can been seen above, i'm getting my downmixed 2ch aac, then copy it into the original with all the other streams - it works, just from reading, i should be able to 1shot this [16:17:02 CEST] <SoreGums> the reason i need the 2ch audio is for some reason device is not mapping the channels properly during the downmix and i have no control over it [16:40:34 CEST] <pgorley> hi, is it normal that after a call to swr_convert_frame, the out AVFrame's nb_samples is still 0? [16:46:51 CEST] <durandal_1707> pgorley: yes [16:47:07 CEST] <durandal_1707> read docs and examples [16:50:05 CEST] <Eldarko> Hello again, guys! :) Could anyone tell me why cant i select a name for a file that is going to be pushed to server via http [16:50:11 CEST] <Eldarko> ffmpeg -i " + url + " -c copy -f hls -hls_time 10 -hls_flags second_level_segment_duration -use_localtime 1 -use_localtime_mkdir 1 -nostdin -loglevel 16 -hls_segment_filename %Y%m%d/%H/%M/segment_%Y%m%d%H%M%S_%%010t.ts -method PUT http://127.0.0.1:9090/live/stream.m3u8 [17:10:18 CEST] <Eldarko_> So, could anyone help with the question above? [17:17:54 CEST] <Eldarko_> https://pastebin.com/uqHkAmmy [17:28:29 CEST] <pgorley> durandal_1707: thanks, that helped me find what was happening [17:28:41 CEST] <pgorley> i was ignoring an input changed error [17:28:53 CEST] <pgorley> and swr_convert was never being called [17:42:45 CEST] <momomo> anyone knows if a universal lnb can recieve ku band frequencies? c-band? [17:44:39 CEST] <Pandela> Morning [17:45:15 CEST] <Pandela> I was curious, is there a way to tell FFmpeg to process an entire file, but skip parts (say the beginning) to apply an effect? [17:50:38 CEST] <pgorley> i keep getting "Input channel count and layout are unset", which options do i need to set on swr_context to fix this? [17:51:44 CEST] <atomnuker> pgorley: you need to set both the input and output frame's sample format, samplerate and channel layout [17:52:18 CEST] <pgorley> atomnuker: on the AVFrame, using av_opt_set_int, or both? [17:52:47 CEST] <atomnuker> on the avframe [17:52:56 CEST] <atomnuker> the opt set stuff is for the swr context [17:53:50 CEST] <pgorley> are those options not set when decoding? [17:55:27 CEST] <atomnuker> on the input avframe they are [17:55:37 CEST] <atomnuker> on the output they're not, since you create the output avframe [17:55:55 CEST] <pgorley> seems the channel layout on my input frame is set to 0 [17:58:42 CEST] <durandal_1707> pgorley: set channel layout based on channel count [17:59:22 CEST] <pgorley> AV_CH_LAYOUT_MONO for 1 and AV_CH_LAYOUT_STEREO for 2, etc, right [17:59:50 CEST] <atomnuker> pgorley: no, its AV_CH_LAYOUT_MONO for mono and AV_CH_LAYOUT_STEREO for stereo [18:01:59 CEST] <Eldarko> Is it possible to set a name pattern for a .ts file when using PUT? [18:02:25 CEST] <Eldarko> or even just a name [18:03:15 CEST] <SpeakerToMeat> And, I have to run, duh, see you all soon :D [18:03:33 CEST] <Eldarko> bye [18:03:53 CEST] <pgorley> durandal_1707, atomnuker: thanks, turns out i just forgot to set AVCodecContext->channel_layout before decoding [18:04:49 CEST] <SpeakerToMeat> I'll leave the question here, I want to combine 6 mono wav files into a single 5.1 track, using this guide https://trac.ffmpeg.org/wiki/AudioChannelManipulation but I have two doubts. A) I need to change the bit depth, do I need to do this for all inputs separatedly or can I do this to the post complex filter map output somehow? and B) in cases where channels are labelable is there any way to have them [18:04:51 CEST] <SpeakerToMeat> rightly tlabeled [18:05:29 CEST] <orbisvicis> how can I determine the actual bitrate of a vbr mp3 file ? [18:05:43 CEST] <orbisvicis> well, average bitrate, min/max bitrate [18:05:56 CEST] <BtbN> "actual" bitrate? [18:06:04 CEST] <BtbN> It's variable, there is no actual bitrate. [18:06:18 CEST] <BtbN> If you want the average, just divide the filesize by the duration [18:09:57 CEST] <orbisvicis> BtbN: how can I get the data filesize, excluding headers/frames ? [18:10:00 CEST] <orbisvicis> and min/max [18:10:27 CEST] <BtbN> an .mp3 file is rather raw, the size of the header barely matter [18:16:14 CEST] <orbisvicis> hmm so duration, according to ffmpeg, is "estimated" from bitrate [18:17:06 CEST] <orbisvicis> is there any tool to tell me the duration, cbr/vbr, average bitrate (cbr/vbr) and min/max bitrate (vbr) ? [18:25:07 CEST] <BtbN> the duration for mp3 should be accurate [18:29:43 CEST] <DHE> that may happen if the input were a pipe or none-file. ffmpeg should seek to the end to read the timestamp on the last sample, right? [18:29:55 CEST] <DHE> otherwise yeah, mp3 duration may be wildly inaccurate if using bitrate alone. [18:30:08 CEST] <Lirk> Hi [18:30:17 CEST] <orbisvicis> no, I get this using `ffmpeg -i` on certain mp3 files [18:30:38 CEST] <Lirk> is there way to get help about ffmpeg postprocessing from command line? [18:31:20 CEST] <Lirk> from source postprocess.c /* -pp Command line Help */ const char pp_help[] = [19:21:26 CEST] <SpeakerToMeat> I want to combine 6 mono wav files into a single 5.1 track, using this guide https://trac.ffmpeg.org/wiki/AudioChannelManipulation but I have two doubts. A) I need to change the bit depth, do I need to do this for all inputs separatedly or can I do this to the post complex filter map output somehow? and B) in cases where channels are labelable is there any way to have them rightly labeled? [19:23:39 CEST] <SpeakerToMeat> I'll try to do a global -c:a see if it works [19:36:26 CEST] <SpeakerToMeat> Btw anybody here well experienced with quicktime? what's the right expected PCM type (alongside prores in case it matters any), signed or unsigned? little or big endian? [19:38:34 CEST] <JEEB> lessee the thing I have around [19:39:00 CEST] <JEEB> pcm_s16be [19:39:08 CEST] <JEEB> is what I have, but I have a feeling it's pretty free [19:42:04 CEST] <SpeakerToMeat> JEEB: I'm checking wikipedia, it seems there's fourcc for both signed le and be, and identifiers for 24 be and 32 be, but these do not denote whether they're signed or unsigned [19:43:17 CEST] <SpeakerToMeat> Wellthey don't specify two's complement like 16 bits le/be so I guess unsigned [19:43:40 CEST] <JEEB> well I just checked what I had in a prores mov file and that was what I just noted :P [19:43:58 CEST] <JEEB> I would guess audio is signed unless specifically noted otherwise [19:44:26 CEST] <JEEB> also you could check what FFmpeg writes with which identifiers in MOV [19:44:35 CEST] <JEEB> wikipedia is not exactly the best of references [19:44:51 CEST] <SpeakerToMeat> Yeah but it has more information than the apple developers document... [19:45:12 CEST] <SpeakerToMeat> Which doesn't even specify whether the in24 fourcc identifier is for BE or LE pcm... [19:45:31 CEST] <JEEB> also there's QTFF dot pdf [19:45:36 CEST] <JEEB> from apple [19:45:52 CEST] <JEEB> (also they seem to have the file format spec as HTML now, too) [19:45:53 CEST] <JEEB> https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QT… [19:47:04 CEST] <SpeakerToMeat> Yeah I should check, I'm here right now https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QT… [19:47:06 CEST] <SpeakerToMeat> thanks [19:47:25 CEST] <JEEB> https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QT… [19:47:40 CEST] <JEEB> this page contains the definition for the identifier I have in my mov file's audio track 'twos' [19:47:43 CEST] <JEEB> for example [19:48:27 CEST] <SpeakerToMeat> Yeah it says twos and raw come from version 0, versions 1 and 2 extend that [19:50:01 CEST] <JEEB> sound sample description box seems to contain formatSpecificFlags which then has endianness etc [19:50:29 CEST] <JEEB> so I would guess the newer four-letter identifiers don't base on that thing itself too much for the endianness [19:53:22 CEST] <SpeakerToMeat> That would make sense, I'm checking the sound descriptors for versions 1 and 2 [20:01:20 CEST] <SpeakerToMeat> Ok for labeling and layout with amerge, is there any way to manually specify a layout for inputs which do not have it? [20:01:26 CEST] <SpeakerToMeat> audio I mean [21:10:14 CEST] <Justanick> Hi, what is the right was if I want to cross compile ffmpeg 3.3.3 but I m not able to execute the cross compiled files on the build host. [21:10:14 CEST] <Justanick> At the moment it fails with zlib requested but not found. [21:10:14 CEST] <Justanick> --target-exec= is not set [21:11:07 CEST] <Justanick> Is ther something like, "use the host compiler for dependency checking"? [21:16:29 CEST] <DHE> well you don't need the host version of zlib. that doesn't actually do you any good [21:18:37 CEST] <Justanick> DHE: I know that I don't need the host version. The target version of the zlib is installed but the test fails with collect2: error: ld returned 1 exit status [21:30:35 CEST] <JEEB> actual error is most likely in ffbuild/config.log [21:32:33 CEST] <Justanick> JEEB: I see only a config.log. There is no folder ffbuild [21:33:36 CEST] <JEEB> ok, then that release is from before ffbuild subdirectory was added [21:33:46 CEST] <JEEB> current master has it under ffbuild/ [21:35:46 CEST] <Justanick> I'm at the moment on 3.3.3 [21:37:26 CEST] <Justanick> JEEB: The config.log is at https://gist.github.com/D-Albers/4d93a769078ddff44fa7373cc91d5b7c [21:41:19 CEST] <Justanick> Any ideas how I can fix this? [21:48:04 CEST] <niklob> hello, " -i video.mkv -i sub.srt -c:v copy -c:a copy -c:s dvbsub output.mkv" returns: [matroska @ 000001cd047cc700] Application provided invalid, non monotonically increasing dts to muxer in stream 2: 229503 >= 27794 av_interleaved_write_frame(): Invalid argument [21:49:08 CEST] <niklob> ffmpeg can't convert srt to dvb ? [21:54:38 CEST] <kepstin> Justanick: do a search for "-lz" in that output to find the linker error. Looks like there's some abi incompatibilities between your libraries and the compiler you're using. [22:00:33 CEST] <Justanick> kepstin: The eroor message is: failed to merge target specific data of file /tmp/ffconf.uwSNapW1.o [22:00:56 CEST] <kepstin> and the line before that, which complains about some different nan modes or something. [22:01:07 CEST] <kepstin> you probably need arch-specific compiler knowledge to fix this :/ [22:02:07 CEST] <Justanick> kepstin: linking -mnan=2008 module with previous -mnan=legacy modules [22:03:34 CEST] <kepstin> Justanick: you'll want to bring that compiler command and linker output to someone who works on the lede/openwrt project toolchain to get help, I suspect it's a bit out of the domain of what most people here know. [22:03:42 CEST] <Justanick> kepstin: Coukd this problem been be triggered through changing the compiler option? If yes, I may have an idea. [22:09:59 CEST] <niklob> How to soft-embed dvb-subs from a .srt-file? [22:18:52 CEST] <Justanick> kepstin: Thanks for the help so far. :) [22:24:29 CEST] <niklob> How can I tell ffmpeg to ignore wrong time value in my srt file? [22:24:42 CEST] <niklob> time values* [22:27:59 CEST] <niklob> nvm [22:28:04 CEST] <niklob> it's a bug in ffmpeg [22:28:07 CEST] <niklob> :( [00:00:00 CEST] --- Wed Aug 16 2017

1 0

ffmpeg-devel.log.20170814
by burek 15 Aug '17

15 Aug '17

[14:09:35 CEST] <cone-410> ffmpeg 03Yogender Gupta 07master:77c5a54192b2: avfilter/scale_npp: fix passthrough mode [14:10:21 CEST] <BtbN> I forgot to commit my local changes... [14:17:39 CEST] <cone-410> ffmpeg 03Timo Rothenpieler 07master:f4ebbda566f7: avfilter/scale_npp: check for buffer allocation failure [15:05:31 CEST] <JEEB> heh, I love the lack of time_base in AVFrames [15:06:24 CEST] <wm4> add it [15:06:32 CEST] <JEEB> just tried using yadif and magically my pts got doubled :) then noticed `link->time_base.den = ctx->inputs[0]->time_base.den * 2;` in vf_yadif [15:07:01 CEST] <wm4> yes you need to use the output sink timebase [15:07:09 CEST] <JEEB> ah right, that's a thing [15:13:12 CEST] <JEEB> so yea, things that could be in AVFrame: frame_type , time_base [15:13:25 CEST] <JEEB> maybe I'll get to adding them one day :V [15:13:39 CEST] <iive> start now :D [15:29:05 CEST] <JEEB> iive: more likely I will start with trying to make a callback in lavf for "program has been updated" [15:29:20 CEST] <JEEB> because I am crazy enough to use lavf for mpeg-ts [15:31:36 CEST] <kierank> JEEB: insane [15:31:41 CEST] <thardin_> madman [15:32:14 CEST] <kierank> I will make sure I take you to the local asylum at vdd [15:32:40 CEST] <JEEB> sounds like the correct action :D [15:32:46 CEST] <JEEB> at least soon enough [15:33:18 CEST] <JEEB> but yea, do we have any other examples of registering callbacks or so from lavf? [15:33:27 CEST] <JEEB> or would I be wading into new territory? [15:36:30 CEST] <wm4> JEEB: what callback? [15:37:21 CEST] <JEEB> wm4: a thing for the mpegts demuxer or so, which would enable me to get a callback called if an AVProgram has gotten updated [15:38:20 CEST] <JEEB> either a pointer in an AVOption (lol) or something else through the avcontext [15:38:25 CEST] <JEEB> *avformatcontext [15:38:30 CEST] <nevcairiel> cant you just diff the programs after every call :p [15:38:42 CEST] <JEEB> nevcairiel: I would guess that is rather inefficient [15:39:56 CEST] <iive> JEEB: doesn't the program table already have a sequence number? [15:40:05 CEST] <wm4> JEEB: some update flag or counter would probably be better [15:40:18 CEST] <wm4> the only callback we have in lavf is the one for opening reference files [15:40:35 CEST] <wm4> and only because there's absolutely no other way to implement this [15:42:19 CEST] <JEEB> wm4: yea, that's another way of doing it. although in theory before you get your next AVPacket multiple PMTs might have happened [15:42:24 CEST] <JEEB> so you'd need an array of ints [15:42:44 CEST] <JEEB> nullptr if no update, [1337, 1338] if updates happened [15:43:50 CEST] <JEEB> iive: nope https://www.ffmpeg.org/doxygen/trunk/structAVProgram.html [15:44:05 CEST] <JEEB> and you just get an array of these [15:44:12 CEST] <JEEB> which get updated when they get [15:44:19 CEST] <wm4> maybe we should have some sort of event thing [15:44:33 CEST] <wm4> where you can get not only packets but also events (as structs) from the demuxer [15:44:40 CEST] <wm4> (still preferable to callbacks) [15:45:04 CEST] <kierank> anyone familiar with h264 in rtp? [15:45:07 CEST] <JEEB> yea, I'm not preferring callbacks. that's just the first thing that came to mind :P [15:45:27 CEST] <JEEB> since people generally herp a derp at the idea of new fields in lavf ctx [15:48:22 CEST] <jkqxz> kierank: Meaning STAPs and FUs? Yes. [15:48:56 CEST] <kierank> jkqxz: so one thing I don't understand in h264 rtp is how long you are meant to buffer [15:49:33 CEST] <iive> JEEB: i was talking about the dvb standard, it has sequence for all the tables that could change, [15:49:47 CEST] <iive> but yeh, having an event signaling stuff is good idea. [15:50:00 CEST] <iive> e.g. imagine been able to handle extradata change. [15:51:05 CEST] <kierank> you get a timestamp for a frame but relative to what? [15:51:41 CEST] <jkqxz> kierank: There are no general rules. [15:52:03 CEST] <wbs> kierank: the rtp timestamps are against an undefined random origin [15:52:04 CEST] <jkqxz> The RTCP lets you match the RTP timestamp to a real clock (and the matching audio clock). [15:52:28 CEST] <kierank> and I guess you build an estimator of the link delay from the rtcp timestamps [15:52:56 CEST] <wbs> you don't need to do that, the rtcp packets just say "rtp time X in the video stream corresponds to realtime clock Y" [15:53:12 CEST] <wbs> so you basically use the latest of those mappings to produce a coherent timeline [15:59:41 CEST] <wm4> iive: we already support extradata changes [15:59:51 CEST] <iive> how? [15:59:54 CEST] <wm4> side data [16:00:12 CEST] <iive> but that needs an actual data? [16:00:17 CEST] <kierank> wbs: i see [16:00:24 CEST] <iive> aka packet [16:00:25 CEST] <wm4> iive: yes [16:00:53 CEST] <iive> how about an null packet that only has side-data? [16:01:08 CEST] <kierank> wbs: but it's still up to the receiver to come up with an estimator of how much to buffer [16:01:18 CEST] <kierank> because I would assume for frame timestamp n, an rtcp packet would also contain timestamp n [16:01:27 CEST] <wm4> iive: API break [16:02:02 CEST] <iive> avi file does have a null packets... how are these handled? [16:02:54 CEST] <jkqxz> kierank: Yes, it's completely up to the receiver. They need to balance their own requirements for real-time-ness vs. possibility of packets turning up later. [16:03:14 CEST] <kierank> I mean buffer enough to keep enough frames available to display [16:03:16 CEST] <kierank> i.e the vbv [16:03:22 CEST] <wm4> iive: discarded [16:03:30 CEST] <kierank> which is in addition to any packet based buffering [16:04:34 CEST] <jkqxz> Traditionally RTP is used in IDR/P-only close-to-CBR cases where that is not an issue. [16:05:12 CEST] <jkqxz> CBR in the "all frames are roughly the same size" sense, not just "within HRD constraints". [16:05:43 CEST] <kierank> ok, makes sense [16:09:47 CEST] <kierank> the whole thing about moving live streaming to webrtc isn't going to work then [16:09:58 CEST] <kierank> without big quality drops if all frames are same size [16:11:47 CEST] <BtbN> Doesn't WebRTC also only support bad codec modes? [16:11:52 CEST] <BtbN> Like, h264 baseline only? [16:14:14 CEST] <jkqxz> There is nothing stopping the receiver using more buffering and adding delay if they want (based on the HRD parameters, I guess). [16:15:36 CEST] <cone-410> ffmpeg 03Timo Rothenpieler 07master:62b75537db15: avfilter/scale_npp: fix logic used in previous patch [16:15:59 CEST] <jkqxz> The all-frames-same-size is just the normal RTP use in videoconferencing-type applications (i.e. what webrtc was originally meant for). [16:16:23 CEST] <BtbN> rabb.it uses WebRTC for live streaming. It's bad. [16:18:28 CEST] <jkqxz> If enough people start using it then it I imagine more support will be hacked in. [16:18:57 CEST] <JEEB> one of the gaming streaming services renamed webrtc to "ftl protocol" [16:18:59 CEST] <BtbN> I couldn't even figure out how to stream to a browser using WebRTC [16:56:21 CEST] <tdjones> atomnuker: Do you have any requirements for my GSoC submission aside from git patches being sent to the mailing list? [17:00:17 CEST] <atomnuker> tdjones: there was something new this year, can't remember, there's still time [17:00:40 CEST] <tdjones> Yeah, they want us to publish it online in some manner [17:01:22 CEST] <tdjones> Didn't know if you wanted it done in any specific way, but just let me know if you think of something [17:02:37 CEST] <atomnuker> k, for now keep at it and improve the patches, with your improvements the field is open for experimentation [17:04:03 CEST] <atomnuker> do send what you come up with a week or so before the deadline (which is in 2 weeks) so it can be polished and upstreamed [17:06:37 CEST] <tdjones> Sure [17:25:51 CEST] <J_Darnley> How does a decoder signal to avcodec that it needs more data before it can return a frame? Is it more than just setting got_picture to 0? Isn't there something about an again return code? [17:26:50 CEST] <atomnuker> no, just set *got_frame to 0 and return a positive number (the packet size or however many bits you've read) [17:27:28 CEST] <J_Darnley> That is what we're doing. [17:28:22 CEST] <kierank> J_Darnley: you're allocating the frame and then doing nothing with it [17:28:24 CEST] <kierank> that's the bug [17:28:27 CEST] <kierank> it's not stored anywhere [17:28:34 CEST] <kierank> you need to take a reference to the buffer [17:28:45 CEST] <kierank> and then output it when you have a complete frame [17:29:09 CEST] <J_Darnley> That was about to be next question, "what about AVFrames". [17:30:18 CEST] <wm4> J_Darnley: depends which API [17:30:27 CEST] <wm4> there are 2 [17:30:31 CEST] <kierank> the normal API [17:30:43 CEST] <wm4> both are normal [17:35:30 CEST] <J_Darnley> Okay, I don't knwow what you mean by that, kierank: [17:35:44 CEST] <kierank> so at the moment we send a fragment to diracdec [17:35:47 CEST] <J_Darnley> When you say "reference" do you mean ffmpeg's reference counting API [17:35:49 CEST] <kierank> it's a sequence header [17:35:57 CEST] <kierank> it allocates a frame [17:36:02 CEST] <kierank> we don't return the frame [17:36:04 CEST] <kierank> the frame leaks [17:36:06 CEST] <J_Darnley> ... or a member in the dirac decoder struct? [17:36:32 CEST] <kierank> not sure if keeping it in a member of the struct is ok or if it needs to be refcounted [17:36:36 CEST] <kierank> I think refcounted [17:36:51 CEST] <kierank> ah *data is a pointer [17:36:56 CEST] <kierank> so it just leaks unless its stored [17:37:12 CEST] <kierank> so maybe not refcounted [17:37:16 CEST] <kierank> just stored in the struct [17:37:22 CEST] <J_Darnley> yeah a void pointer maing it so obvous what's there [17:37:27 CEST] <atomnuker> you can do the following: call get_buffer on field 1 with the full frame size, decode to it and have a pointer in your context to it [17:37:41 CEST] <kierank> it's not about field 1 [17:37:47 CEST] <kierank> it's about indepdently decodable slices [17:37:52 CEST] <atomnuker> then during field 2 don't call get buffer, write to field 1's avframe and transfer the reference to the current avframe [17:37:58 CEST] <atomnuker> ah, ok [17:37:59 CEST] <kierank> atomnuker: already implemented [17:38:07 CEST] <kierank> by you in fact [17:38:13 CEST] <J_Darnley> :) [17:38:30 CEST] <atomnuker> I don't remember what the trimmed decoder does but I don't think it does that [17:42:52 CEST] <J_Darnley> I see the decoder calling av_frame_ref for something about fields. [17:43:15 CEST] <kierank> atomnuker: trimmed does exactly that [17:43:40 CEST] <kierank> J_Darnley: can you check my hypothesis is correct with valgrind [17:43:43 CEST] <kierank> i think the avframe leaks [17:43:48 CEST] <J_Darnley> okay [17:44:11 CEST] <kierank> atomnuker: there is a new vc-2 spec that implements fragments (i.e groups of slices) which we feed to the decoder individually [17:44:17 CEST] <kierank> hence things have changed quite a bit [17:45:00 CEST] <J_Darnley> Thanks for backtracing those log messages, valgrind. [17:45:30 CEST] <J_Darnley> Nothing is leaked. [17:46:12 CEST] <J_Darnley> Unless that is part of the ~5k "still reachable" [17:47:54 CEST] <kierank> ok then i dunno why ffmpeg complains about frame size changing [17:47:57 CEST] <kierank> you'll need to look into that [17:48:06 CEST] <kierank> in theory it should do the right thing, count the slices until they are done [17:48:17 CEST] <kierank> if need be break non-fragmented hq mode, I don't care any more [17:48:18 CEST] <J_Darnley> I agree. [17:48:56 CEST] <atomnuker> kierank: lol, I'm looking at the code and I can't figure out what happens [17:49:10 CEST] <kierank> atomnuker: for what case? [17:49:16 CEST] <atomnuker> interlaced [17:49:36 CEST] <atomnuker> I can't see where the buffer gets transferred and outputted during the second field [17:50:04 CEST] <atomnuker> the data avframe doesn't get touched during the second field [17:50:15 CEST] <atomnuker> how is it outputting stuff during the second field? [17:50:57 CEST] <atomnuker> ah, nevermind [17:51:04 CEST] <atomnuker> av_frame_ref(data, s->current_picture) [17:51:13 CEST] <kierank> "/* Picks the field number based on the parity of the picture number */" [17:51:14 CEST] <kierank> yeah [17:51:57 CEST] <atomnuker> clever, it creates a reference in the output avframe from the internal one [18:32:17 CEST] <J_Darnley> kierank: no more error, but now I am leaking things [18:34:40 CEST] <kierank> ok [18:35:24 CEST] <J_Darnley> oh, and no allocated buffer for the planes. [18:35:46 CEST] <kierank> huh [18:35:51 CEST] <kierank> that's clearly broke then [18:35:57 CEST] <J_Darnley> Yes! [18:41:28 CEST] <J_Darnley> Oh, that was my mistake. I put the idwt in the wrong place. [18:42:40 CEST] <J_Darnley> Good news: the chroma is no longer green, we now have a nice 50% gray image [18:43:38 CEST] <kierank> are you doing the slice unpack [18:44:06 CEST] <J_Darnley> Probably not. Did I miss something? [18:44:25 CEST] <kierank> decode_hq_slice [18:44:28 CEST] <kierank> actually decoding the coefficients [18:44:36 CEST] <J_Darnley> Ha. [18:44:43 CEST] <J_Darnley> Yeah, probably [18:44:48 CEST] <kierank> do it linearly don't try and thread it [18:44:55 CEST] <J_Darnley> noted [19:19:30 CEST] <J_Darnley> kierank: I think I've got it. [19:20:05 CEST] <kierank> definitely worth fuzzing if it works and doesn't leak [19:20:07 CEST] <J_Darnley> I see the zoneplate pattern [19:20:43 CEST] <J_Darnley> Oh, I think it still leaks [19:21:51 CEST] <J_Darnley> Yeah, I didn't change that bit. [19:22:20 CEST] <kierank> and multiple frames works? [19:22:21 CEST] <J_Darnley> To all: how do you use av_frame_ref correctly? [19:22:44 CEST] <J_Darnley> kierank: I haven't made a sample like that [19:22:55 CEST] <J_Darnley> Myabe I should do that first [19:22:55 CEST] <kierank> J_Darnley: the sample on .18 is like that [19:23:19 CEST] <J_Darnley> Really? [19:23:35 CEST] <kierank> yes, I think it's 40 frames or something [19:23:57 CEST] <kierank> ah no [19:23:58 CEST] <kierank> my bad [19:24:09 CEST] <kierank> anyway make one work without a leak [19:24:12 CEST] <kierank> and fuzz crash [19:24:14 CEST] <kierank> then go onto more [19:24:18 CEST] <J_Darnley> okay [19:24:38 CEST] <J_Darnley> Continuing my question... [19:25:39 CEST] <kierank> you allocate a frame and you get 1 ref to it [19:25:42 CEST] <J_Darnley> Yes [19:25:44 CEST] <J_Darnley> I'm using av_frame_ref to make a reference into the dirac decoder struct after I allocate [19:25:44 CEST] <kierank> then you ref it to get another one [19:26:20 CEST] <J_Darnley> I'm using av_frame_ref to make a reference into the dirac decoder struct after I allocate a frae on the first fragment given to the decoder [19:27:04 CEST] <kierank> so you need to assume that anything you put into *data gets freed afterwards [19:27:10 CEST] <J_Darnley> Then when I have decoded the picture I am using av_frame_ref again to copy properties back into the output AVFrame [19:27:21 CEST] <kierank> then you have a refcount of two [19:27:28 CEST] <kierank> and after decode_frame it has a refcount of 1 so leaks [19:27:35 CEST] <kierank> I think [19:27:46 CEST] <kierank> but i thought you'd reuse the frame so maybe it should have a refcount of 1 [19:28:07 CEST] <J_Darnley> I don't know what any of this does [19:28:14 CEST] <kierank> J_Darnley: refcounting [19:28:14 CEST] <J_Darnley> I hate garbage collection garbage. [19:28:19 CEST] <kierank> nonsense [19:28:28 CEST] <kierank> refcounting was a patch that took ffmpeg into the 21st century [19:28:43 CEST] <JEEB> true [19:29:04 CEST] <kierank> ok libavcodec to be more precise [19:29:08 CEST] Action: J_Darnley prefers the stoneage [19:29:20 CEST] <durandal_1707> lol [19:29:45 CEST] <kierank> good luck sharing frames between threads [19:31:01 CEST] <J_Darnley> So when do I call free or unref or whatever? [19:31:02 CEST] <kierank> J_Darnley: so yes i am right [19:31:07 CEST] <kierank> you don't free [19:31:16 CEST] <kierank> you only ref the frame if you need to keep a copy [19:31:18 CEST] <atomnuker> yep, refcounting absolutely rocks and saves on so much memcpys [19:31:33 CEST] <kierank> J_Darnley: so you keep a copy of the frame during the fragments [19:31:44 CEST] <kierank> then pass it to *data on the way out [19:31:45 CEST] <kierank> afaik [19:32:02 CEST] <kierank> J_Darnley: I will convert you to refcounting like I convertered atomnuker [19:32:05 CEST] <kierank> it was a struggle but I won [19:32:26 CEST] <kierank> J_Darnley: the current problem is we store the frame in *data [19:32:30 CEST] <kierank> instead of the struct [19:32:35 CEST] <kierank> and so *data is freed automatically [19:33:08 CEST] <J_Darnley> Not anymore. I made a ref using a new AVFrame in the diracdec struct. [19:33:25 CEST] <J_Darnley> Do I write that address into *data then? [19:33:32 CEST] <kierank> you don't need to make a ref in the struct [19:33:38 CEST] <kierank> you go direct [19:33:43 CEST] <kierank> then put that into *data when the frame is done [19:35:16 CEST] <J_Darnley> ? I'm sure *data is being saved into one of the other 3 AVFrame* in the struct on the first fragment. [19:36:08 CEST] <kierank> huh [19:36:11 CEST] <kierank> data is the output [19:36:41 CEST] <kierank> data = frame <-- then ffmpeg does what it wants [19:37:16 CEST] <kierank> J_Darnley: you're sure the avframe is leaking from valgrind [19:37:18 CEST] <kierank> can you patch .18 [19:37:20 CEST] <kierank> and I can look [19:38:38 CEST] <J_Darnley> Okay [00:00:00 CEST] --- Tue Aug 15 2017

1 0

ffmpeg.log.20170814
by burek 15 Aug '17

15 Aug '17

[00:20:43 CEST] <sh4rm4^bnc> what's the trick to get ffprobe to report length for all of a dvd's VOB files ? [00:21:21 CEST] <sh4rm4^bnc> i tried using concat:file1.VOB|file2.VOB, and looping over all vobs and adding up the size [00:21:47 CEST] <sh4rm4^bnc> the concat thing just returns length for the last VOB in the list [00:22:27 CEST] <sh4rm4^bnc> and looping over single files gets erroneus results, for example VTS_01_4.VOB is reported to have 90000 seconds [00:54:09 CEST] <dystopia_> ffprobe -i "concat:VTS_01_1.VOB|VTS_01_2.VOB|VTS_01_3.VOB|VTS_01_4.VOB|VTS_01_5.VOB|VTS_01_6.VOB" [00:54:10 CEST] <dystopia_> maybe [01:29:08 CEST] <sh4rm4^bnc> dystopia_, thanks, but as i said, this returns only the length of the last file [01:46:51 CEST] <c_14> sh4rm4^bnc: there's no good solution besides iterating over each file and getting the duration there (if necessary by actually counting frames/pts) [01:47:20 CEST] <c_14> Well, I guess you could use concat and ffmpeg to create a file and grab the reported output duration of that [01:56:32 CEST] <sh4rm4^bnc> c_14, is there an advantage over using ffmpeg for that instead of cat *.VOB > foo.vob ? [01:57:21 CEST] <sh4rm4^bnc> (that's what i wanted to avoid to begin with; i need the length for automatic framerate calculation to encode the dvd as mp4) [01:59:23 CEST] <c_14> If you're using the concat protocol, not really. Using tccat might be a better alternative [01:59:50 CEST] <sh4rm4^bnc> btw i would have expected that dvd metadata files have the length info, but my tried to use dvd://path didnt work out... [02:00:20 CEST] <c_14> they should [02:01:02 CEST] <sh4rm4^bnc> so there's probably a trick to make ffprobe read the info from the metadata, instead of scanning the vob's [02:01:23 CEST] <c_14> Probably a deficiency in the code if anything [02:01:56 CEST] <sh4rm4^bnc> well, i find it quite deficient that the concat:foo|bar input doesn't work as expected [02:02:42 CEST] <c_14> the duration reported by ffprobe is only metadata [02:02:48 CEST] <c_14> and for that it just uses the first file [02:03:00 CEST] <c_14> you could use -count_frames and some extra options to get all the frame pts [02:03:06 CEST] <c_14> but those'll probably wrap [02:03:13 CEST] <c_14> So you'd have to catch that and add it all up yourself [02:04:48 CEST] <sh4rm4^bnc> haha, -count_frames makes ffmpeg segfault [02:05:00 CEST] <sh4rm4^bnc> or ffprobe, rather [02:05:08 CEST] <c_14> version? [02:05:22 CEST] <sh4rm4^bnc> ffprobe version 3.2.3 Copyright (c) 2007-2017 the FFmpeg developers [02:06:02 CEST] <c_14> That's relatively new I guess [02:06:04 CEST] <c_14> weird [02:06:08 CEST] <c_14> linux? [02:06:12 CEST] <sh4rm4^bnc> yes [02:06:16 CEST] <c_14> Try [02:06:18 CEST] <c_14> http://johnvansickle.com/ffmpeg/ [02:06:20 CEST] <c_14> A build from there [02:06:54 CEST] <sh4rm4^bnc> nope sorry - i use only sw built myself from source [02:07:13 CEST] <c_14> can you build from git then? [02:07:13 CEST] <sh4rm4^bnc> also i use musl libc, so that one is almost certainly not compatible anyway [02:07:16 CEST] <c_14> git master head? [02:07:25 CEST] <sh4rm4^bnc> i guess i could try that [02:07:28 CEST] <c_14> I just recommended that because most people are lazy [02:36:08 CEST] <sh4rm4^bnc> no segfault with latest git snapshot... though it's either dead-slow, or stuck in an endless loop [02:36:35 CEST] <sh4rm4^bnc> i started the command like 10 mins ago, still not finished [02:36:56 CEST] <c_14> count_frames can take a while [02:36:57 CEST] <c_14> though not _that_ long usually [02:37:34 CEST] <sh4rm4^bnc> PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command [02:37:34 CEST] <sh4rm4^bnc> 25885 user 20 0 95612 22264 12012 R 99.8 0.1 11:52.75 ffprobe -v error -show_entries format=dura [02:39:28 CEST] <sh4rm4^bnc> it's on the first vob file, which without count_frames reports a length of 29 secs [02:40:00 CEST] <c_14> the thing with count_frames is that it won't necessarily make your result better if you don't work with it, if your content is cfr you can grab the total number of frames with format=nb_read_frames, otherwise you'll have to dump info on every frame with show_frames or similar to get the pts of each of them [02:48:08 CEST] <sh4rm4^bnc> still running, i think we can officially declare it to be an endless loop [02:48:22 CEST] <sh4rm4^bnc> let's see if i can get a backtrace [02:59:51 CEST] <sh4rm4^bnc> for some reason gdb can't associate the program counter with the source code addresses, so bad luck i guess [03:00:32 CEST] <sh4rm4^bnc> only thing i can tell is that memset is called in the loop with small buffers of maybe 32 bytes max [03:01:16 CEST] <sh4rm4^bnc> anyway, let me know if you need further info, c_14 (assuming you're a dev interested in fixing this) [03:02:28 CEST] <c_14> Im not much of a dev and I'm busy these days anyway, but you could open a bug report on trac though without a reproducer getting a fix would be hard [03:02:41 CEST] <c_14> To fix your actual problem, I would recommend using tccat or something though [05:32:01 CEST] <c3r1c3-Win> danieel: i need a log, not a screenshot. [05:32:28 CEST] <c3r1c3-Win> Sorry... I somehow ended up in this chat. [06:22:49 CEST] <sh4rm4^bnc> hmm, when i encode stuff with libx264, the resulting video can only be watched if it is completely downloaded, unlike e.g. youtube videos where you can watch while you download. i get this error: [06:22:52 CEST] <sh4rm4^bnc> [ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: moov atom not found [06:22:52 CEST] <sh4rm4^bnc> [lavf] avformat_open_input() failed [06:23:17 CEST] <sh4rm4^bnc> is there a trick to produce a "streamable" video ? [06:23:47 CEST] <relaxed> you need -movflags faststart [06:24:02 CEST] <sh4rm4^bnc> cool, thanks [06:24:15 CEST] <furq> you shouldn't need that any more unless your browser is really old [06:24:22 CEST] <furq> although it's still a good idea in general [06:24:37 CEST] <thebombzen> sh4rm4^bnc: keep in mind that if you encode with -movflags +faststart, you still need to write the whole file. it's not stremable in the sense that you can view partial files [06:24:48 CEST] <furq> right [06:24:52 CEST] <furq> you'd need to use a different muxer for that [06:24:53 CEST] <sh4rm4^bnc> i encode stuff on an fast server, then download it, trying to watch it with mpv while it plays [06:25:01 CEST] <relaxed> the + isn't needed [06:25:02 CEST] <furq> while it encodes, you mean? [06:25:09 CEST] <furq> in that case use mkv [06:25:12 CEST] <sh4rm4^bnc> no, after it is encoded [06:25:17 CEST] <furq> oh [06:25:18 CEST] <thebombzen> relaxed: it should be used though [06:25:33 CEST] <furq> tbh you should probably still use mkv unless you have a good reason to prefer mp4 [06:25:40 CEST] <furq> but if you want to use mp4 then do what relaxed said [06:26:00 CEST] <relaxed> it should be used for multiple flags [06:26:08 CEST] <thebombzen> sh4rm4^bnc: mp4 files have a table of contents (called the moov atom) that by default is at the end of the file and it's created when the file is ready to be finished [06:26:42 CEST] <thebombzen> you can't read the mp4 file without the moov atom. but -movflags +faststart moves it to the front of the file when writing to a seekable device, which means that browsers can start it immediately [06:26:43 CEST] <sh4rm4^bnc> i see [06:26:49 CEST] <furq> browsers will usually seek to the end of the file to download the moov atom now [06:26:58 CEST] <furq> but if you're using scp or something then obviously that's not going to work [06:27:11 CEST] <thebombzen> this also requires the http server to support seeking, which it might not if it's old [06:27:36 CEST] <sh4rm4^bnc> i download with wget :) [06:27:50 CEST] <thebombzen> well there you go [06:28:16 CEST] <thebombzen> if you use a primitive browser like wget or curl to download it sequentially, you have the issue described above. [06:28:56 CEST] <sh4rm4^bnc> can libx264 be used with mkv ? and if so, what's the advantage ? [06:29:15 CEST] <furq> yes and the advantage is you don't need to rewrite the entire file when it's done encoding to put the moov atom at the start [06:29:30 CEST] <furq> more or less everything is compatible with mkv [06:29:46 CEST] <furq> (except timebases that aren't a power of 10, but ignore that for now) [06:29:50 CEST] <sh4rm4^bnc> oh great. i just use foo.mkv as output filename instead of foo.mp4 ? [06:29:51 CEST] <thebombzen> most browsers will not autoplay matroska files [06:30:00 CEST] <furq> well he's not using a browser so that's fine [06:30:02 CEST] <furq> sh4rm4^bnc: yeah [06:30:12 CEST] <c3r1c3-Win> Just remux if you need the mp4 file. [06:30:14 CEST] <thebombzen> don't use -movflags +faststart though, that's a mp4-specific option [06:30:34 CEST] <sh4rm4^bnc> ok, thanks [06:30:35 CEST] <thebombzen> (er, mov, mp4, m4a, 3gp, 3g2, mj2, but whatever) [06:30:53 CEST] <furq> also if you already encoded these files then you don't need to reencode them [06:31:06 CEST] <furq> you can just copy the streams into mkv or whatever [06:32:00 CEST] <sh4rm4^bnc> ah, how can i do that ? [06:32:23 CEST] <furq> -i foo.mp4 -map 0 -c copy bar.mkv [06:33:51 CEST] <sh4rm4^bnc> nice [08:15:56 CEST] <thunfisch> is it possible to print an AVFormatContext property with the ffmpeg comand line? need to get the 'rtcp_ts_offset' value that is being set in libavformat/rtsp.c:2188 @master [08:16:02 CEST] <thunfisch> want to avoid writing custom code [08:17:53 CEST] <thunfisch> or even better: set dts to that value [13:35:48 CEST] <Vonor> getting on latest git checkout: x86_64-pc-linux-gnu-gcc is unable to create an executable file. using gcc 4.8.5 -> http://paste.opensuse.org/65205285 [13:38:39 CEST] <durandal_1707> what is error? [13:39:12 CEST] <Vonor> that is the error [13:39:19 CEST] <BtbN> there's no error in that log [13:39:33 CEST] <bencoh> Vonor: you should paste the full configure log [13:39:46 CEST] <Vonor> the log shows only gcc -v [13:40:36 CEST] <Vonor> erm, the output of the configure script has that as first line, then suggests about cross compiling (which is not the case ) and says "C compiler test failed". that's it [13:41:34 CEST] <Vonor> ah. there's a build log. heh. didn't see that before. my bad. here's the actual line: x86_64-pc-linux-gnu-gcc -march=k8 -mtune=core2 -O2 -pipe --static -fPIE -march=core2 -c -o /tmp/ffconf.cFXFnAgx/test.o /tmp/ffconf.cFXFnAgx/test.c [13:41:34 CEST] <Vonor> ./configure: line 892: x86_64-pc-linux-gnu-gcc: command not found [13:42:47 CEST] <furq> pastebin the full configure log [13:47:23 CEST] <Vonor> http://arin.ga/4AdqDq [13:47:57 CEST] <furq> --cc=x86_64-pc-linux-gnu-gcc [13:48:12 CEST] <ScottSteiner> I have a video that I sped up 8x. I want to put a timestamp on it, but the drawtext filter doesn't support a framerate of 400/1. How do I generate a transparent video with the timestamp so I can speed it up and then merge it with the original video? [13:48:24 CEST] <furq> you probably don't want to set --cc etc if you're not cross compiling [13:48:30 CEST] <furq> especially not to something that doesn't exist [13:50:45 CEST] <Vonor> ehh..do'h. that configure line was from a gentoo environment i had before. thanks for the hint. [13:52:50 CEST] <furq> ScottSteiner: what do you mean "doesn't support a framerate of 400/1" [13:52:54 CEST] <furq> that seems to work fine here [13:53:17 CEST] <ScottSteiner> I get error message "[Parsed_drawtext_0 @ 0x1e18d00] Timecode frame rate 400/1 not supported" [13:53:40 CEST] <ScottSteiner> Could it be a codec/container issue? I'm putting it into a libvpx webm [13:54:02 CEST] <Vonor> hmm. missing some libararies i guess. it's complaining now that ld cannot find -lpng and -lc i got libpng12, libpng16 and their respective -devel packages installed. [13:54:03 CEST] <furq> that shouldn't matter [13:55:45 CEST] <furq> ScottSteiner: pastebin the command and full output [13:56:14 CEST] <ScottSteiner> https://paste.debian.net/plain/981285 [14:02:03 CEST] <furq> oh right i actually get a similar error [14:02:19 CEST] <furq> timecode_rate only works here if i set it to 30 or 60 [14:02:43 CEST] <ScottSteiner> yeah, i was just looking at the code https://www.ffmpeg.org/doxygen/2.1/libavutil_2timecode_8c_source.html supported_fps[] = {24, 25, 30, 50, 60}; [14:03:39 CEST] <ScottSteiner> so I need to create a blank image with just the timer on an alpha channel...How would I do that? [14:04:04 CEST] <furq> you can use text=${pts\:hms} for a millisecond timestamp [14:04:12 CEST] <furq> that'll at least give you a unique value per frame [14:04:21 CEST] <furq> i don't see how you'd get a proper timecode at 400fps though [14:04:34 CEST] <furq> er, %{} [14:04:42 CEST] <ScottSteiner> I can already generate the timestamp [14:04:55 CEST] <ScottSteiner> My plan is to create a video of the full length and then speed that one up too [14:05:13 CEST] <ScottSteiner> it should be a bit faster since I'll be doing it at a different bitrate [14:05:53 CEST] <furq> what are you actually doing [14:06:00 CEST] <furq> i just noticed your output video is 60fps and now i'm confused [14:06:01 CEST] <ScottSteiner> putting a timer on a video [14:06:49 CEST] <ScottSteiner> I have a video that I sped up 8x. I want to put a timestamp on it, but preserve the original timing [14:07:14 CEST] <ScottSteiner> I don't want to re-encode the entire thing because it's a rather large file that took a few hours to encode initially [14:14:44 CEST] <furq> ffmpeg -f lavfi -i color=white@0.0:d=1234,format=rgba,drawtext="timecode='00\:00\:00\.000':timecode_rate=60" -c:v ffv1 out.nut [14:14:52 CEST] <furq> something like that will draw the timecode on a transparent background [14:15:00 CEST] <furq> replace d=1234 with the actual duration [14:26:59 CEST] <ScottSteiner> thanks furq, I'll try that out [14:33:17 CEST] <furq> actually that might be a dumb way of doing it [14:33:29 CEST] <Vonor> using this as configure line -->> ./configure --pkg-config-flags="--static" '--extra-cflags=--static' '--extra-cxxflags=--static' --disable-shared --enable-static --disable-gpl --disable-nonfree <<-- I would expect to get a static binary. But I'm getting a dynamically linked one :-( -->> ffmpeg: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.0.0, BuildID[sha1]=3f1b52e39bab32a7d454a06113e [14:33:29 CEST] <Vonor> 2c29b5015aa2f, stripped [14:33:39 CEST] <furq> if you're encoding it again anyway then the right thing is probably to do -vf drawtext=[options],fps=400 on the source video [14:33:47 CEST] <furq> that'll give you a 60fps timecode on a 400fps video [14:33:57 CEST] <furq> or whatever the source framerate is [14:53:34 CEST] <ScottSteiner> I did " ffmpeg -i input.webm -vf drawtext="fontcolor=black:fontsize=48:timecode='00\:00\:00\.000':timecode_rate=60:text=''",fps=400 output.webm" but the timestamp was shown in realtime, but sped up [14:53:52 CEST] <ScottSteiner> with input.webm being the sped up video [15:09:10 CEST] <ScottSteiner> maybe ill just bite the bullet and re-encode the whole thing. trying to find workarounds seems to be more painful than just letting it run in the background [15:11:03 CEST] <dystopia_> wrong framerates maybe? [15:11:33 CEST] <ScottSteiner> not that I can see [15:32:38 CEST] <ScottSteiner> it ended up not being too bad, the frames being dropped since I chained my atempo/setpts filters really sped things up [18:19:57 CEST] <pgorley> hi, how would i put AVFrame->data into an std::vector<uint8_t>? [18:20:08 CEST] <c_14> memcpy? [18:21:53 CEST] <pgorley> c_14: i was trying the iterator ctor approach, but it seems to segfaults, is there a way to get a pointer to the last item in AVFrame->output? [18:25:34 CEST] <c_14> You mean AVFrame->data ? [18:26:52 CEST] <c_14> use the width * height? [18:39:44 CEST] <BtbN> height * linesize [18:45:01 CEST] <c_14> eeh, right [18:51:56 CEST] <pgorley> BtbN, c_14: thank you [18:52:13 CEST] <pgorley> but yea, AVFrame->data [19:43:53 CEST] <pgorley> i think i'm going about this wrong [19:45:06 CEST] <pgorley> i'm working with an application that takes an array of audio samples for each channel (each channel is an int16_t*) and i want to put my audio file in there [19:46:07 CEST] <durandal_1707> AVFrame stores channels in extended_data[x] [19:46:27 CEST] <durandal_1707> where x is 0 for packed sample format [19:46:54 CEST] <durandal_1707> or x is channel number in case of planar sample format [19:47:27 CEST] <pgorley> so i would just append extended_data to my array each time i decode a frame? [19:48:28 CEST] <durandal_1707> something like that [19:48:34 CEST] <pgorley> hmm [19:49:14 CEST] <durandal_1707> but make sure its still same endianess, sample fmt is in native endianess [19:49:29 CEST] <pgorley> and how do i know if my format is packed or planar? [19:49:35 CEST] <pgorley> oh, nvm found it [19:50:12 CEST] <pgorley> av_sample_is_planar and then use av_samples_get_buffer_size to get the size of extended_data? [19:51:35 CEST] <pgorley> durandal_1707: i'll try it out, thanks! [19:51:44 CEST] <durandal_1707> size of extended data is nb of decoded samples * sizeof( sample ) in bytes [19:53:50 CEST] <pgorley> durandal_1707: how do i get the size of a sample? since i'm putting it in an array of int16_t, would it be 2? [19:54:19 CEST] <durandal_1707> if decoded sample format is int16 [19:54:45 CEST] <durandal_1707> if not than you need to resample using libswresample [19:56:06 CEST] <pgorley> i see, so i would need to check if the samle format is int16 and if not call swr_convert on it? [19:56:29 CEST] <durandal_1707> yes [19:57:02 CEST] <pgorley> this is starting to make sense, thanks a lot! [19:57:26 CEST] <CyBerNetX> hello [19:57:42 CEST] <durandal_1707> hello [19:58:05 CEST] <CyBerNetX> i serach info in this page https://trac.ffmpeg.org/wiki/RemapFilter [19:58:24 CEST] <CyBerNetX> i hav made the project bin [19:58:55 CEST] <CyBerNetX> but i dont understand this [19:59:17 CEST] <durandal_1707> what exactly? [19:59:25 CEST] <CyBerNetX> i test on a file who have 2 spherical view [19:59:54 CEST] <CyBerNetX> 1 front and [20:00:04 CEST] <CyBerNetX> bak side [20:00:34 CEST] <voip_> Hello guys, please help me with problem: Selected ratecontrol mode is not supported by the QSV runtime. [20:00:42 CEST] <voip_> https://pastebin.com/fQ2xGN6M [20:00:51 CEST] <BtbN> Use a rate control mode that it supports [20:00:54 CEST] <CyBerNetX> i think the binarie is used to made remap on 1 spherical view ? [20:01:20 CEST] <JEEB> voip_: you have not set a rate control mode and I guess the global default is 200kbps bit rate [20:01:29 CEST] <JEEB> that is not supported by that encoder [20:01:45 CEST] <CyBerNetX> but my camera has 2 fisheye one on front and 1 one backside [20:01:47 CEST] <JEEB> also I'm pretty sure the QSV encoder has no knowledge of x264 presets [20:02:58 CEST] <durandal_1707> CyBerNetX: map files work only for layouts mentioned in wiki [20:03:27 CEST] <CyBerNetX> ok thanks [20:08:09 CEST] <voip_> JEEB, how can fix and set rate control [20:08:10 CEST] <voip_> ? [20:14:26 CEST] <voip_> JEEB, i tryed with h264_qsv -b:v 2500k same problem [20:36:30 CEST] <voip_> guys, how can i setup rate control ? I also i tried with h264_qsv -b:v 2500k same problem [20:37:52 CEST] <pgorley> in multichannel audio, are all AVFrame->extended_data arrays the same size? [20:38:11 CEST] <BtbN> voip_, try also specifying a maxrate [20:39:57 CEST] <voip_> tryed, same problem :( [20:46:13 CEST] <jkqxz> voip_: Making libmfx work on Linux is painful. Make sure you are using the modified kernel and all of the modified libraries (and that your distribution isn't overriding them with normal versions). [20:47:45 CEST] <BtbN> Or just use libva [20:47:49 CEST] <jkqxz> If transcoding locally in CBR mode (like "-b:v 1M -maxrate 1M") doesn't work then there is probably something wrong with your setup. The whole thing is hopelessly undebuggable, "strace" is about the best tool for working out what it's actually doing. [20:49:23 CEST] <voip_> guys i think its setup problem. because i follow instructions and test command (fmpeg -y -i test.mp4 -vcodec h264_qsv -acodec copy -b:v 8000K out.mp4) give me same error [22:15:37 CEST] <paveldimow> Hi, I have two incoming (live) rtmp streams, I would like pick the video from one stream and audio from another stream and to sync them. Is this possible with ffmpeg? [22:16:08 CEST] <BtbN> syncing two unrelated streams is most likely close to impossible [22:17:06 CEST] <JEEB> it's not impossible but you will have to make concessions/have a buffer if they are offset by enough time [22:18:44 CEST] <BtbN> one slight network-stutter and they will be permanently out of sync again until you restart [22:19:17 CEST] <paveldimow> what do you mean by unrelated? [22:19:38 CEST] <JEEB> BtbN: wouldn't the PTS matching still be the same [22:19:55 CEST] <BtbN> I don't think ffmpeg cares about PTS for seperate input sources [22:20:00 CEST] <BtbN> it treats them as unrelated [22:20:03 CEST] <JEEB> yes [22:20:08 CEST] <JEEB> which is why you have to write hte code yourself [22:20:22 CEST] <JEEB> you take in two inputs, you know the approximate difference and start matching PTS [22:20:31 CEST] <JEEB> (using a buffer for the one that's ahead) [22:20:40 CEST] <BtbN> That does assume that the PTS are identical though [22:20:44 CEST] <BtbN> which they most likely won't be [22:21:08 CEST] <JEEB> not identical, but that the offset will not change - you would have to make an interface that takes in change requests for it if it is variable [22:21:26 CEST] <paveldimow> hmmm [22:21:48 CEST] <paveldimow> so, to sum, it's possible but very hard [22:22:11 CEST] <JEEB> possibly not very hard, but "not something achievable with the ffmpeg.c command line app as-is" [22:22:16 CEST] <paveldimow> ok, does it matter if the input streams are created with the same application? [22:22:27 CEST] <JEEB> why would it? [22:23:04 CEST] <paveldimow> I don't know, beacuse of "[22:20] <BtbN> That does assume that the PTS are identical though [22:20] <BtbN> which they most likely won't be" [22:24:22 CEST] <paveldimow> well ok, what do you think how much if take time/money to make this solution with ffmpeg? [22:24:43 CEST] <paveldimow> we are talking about days/months/years? [22:25:11 CEST] <paveldimow> just asking, I don't know if you are developers [22:26:12 CEST] <JEEB> depends on your experience with the libav* APIs [22:26:33 CEST] <JEEB> and in general your grasp on the idea of having two inputs and buffering one until you get to the same point in your other stream [22:27:24 CEST] <paveldimow> how about your experience? :) [22:27:53 CEST] <JEEB> the dynamic buffer would be the thing for me to watch out for, otherwise it sounds relatively straightforward [22:28:17 CEST] <BtbN> until someone restarts one of the input streams, and everything's messed up [22:28:32 CEST] <JEEB> yes, and that's when you have to then re-adjust the dynamic buffer again [22:28:39 CEST] <JEEB> and the desync rate [22:28:55 CEST] <JEEB> I mean, far from being perfect but that's what you get when you want to sync two unrelated things together [22:28:58 CEST] <BtbN> I'd have no idea how to do that in any reliable way [22:29:08 CEST] <paveldimow> it can be static as well or no? I mean give it enough size [22:29:33 CEST] <paveldimow> well, does it help if we consider one "master" stream to be super reliable? [22:29:41 CEST] <BtbN> someone would have to constantly babysit it, and manually adjust the delay [22:30:07 CEST] <paveldimow> well, manual adjust is not an option... at least for now :) [22:30:21 CEST] <BtbN> The only reliable way to do things like that is realtime timestamps and synced clocks. But I don't think rtmp even supports that [22:30:36 CEST] <JEEB> yea, unless you code it into special SEI messages or something [22:30:40 CEST] <JEEB> and add parsing of that to lavf [22:31:06 CEST] <JEEB> or use the UTC timestamp as FLV timestamp? not sure how big the values can be [22:31:15 CEST] <JEEB> only remember how it was a time base of 1/1000 [22:31:18 CEST] <paveldimow> 32bit [22:31:35 CEST] <paveldimow> which is quite enough [22:31:36 CEST] <BtbN> rtmp timestamps wrap around after roughly 45 hours [22:31:43 CEST] <BtbN> realtime timestamps wouldn't work [22:31:54 CEST] <paveldimow> no no, no need to more then 2-3 hours [22:32:10 CEST] <BtbN> Well, the unix time started 1970 though [22:32:38 CEST] <JEEB> anyways, if you can sync the source clocks and use timestamps as your PTS then, uh [22:32:44 CEST] <JEEB> suddenly the problem becomes a bit simpler [22:33:10 CEST] <BtbN> If you manage to ensure the PTS are identical on all inputs, you can hack something, yes. But ffmpeg.c still can't do it. [22:33:36 CEST] <paveldimow> what do you mean byt PTS are identical? [22:33:48 CEST] <JEEB> PTS = presentation time stamp [22:34:27 CEST] <paveldimow> yes yes, but why when if I understand correctly, rtmp does not support absolute timestamps only relative [22:34:47 CEST] <JEEB> RTMP = FLV, FLV AFAIK supports PTS just fine [22:34:56 CEST] <JEEB> go read the FLV specs if you care enough [22:34:57 CEST] <BtbN> There are no relative timestamps [22:35:06 CEST] <BtbN> They are always absolute to a random timebase [22:35:52 CEST] <paveldimow> Timestamps in RTMP are given as an integer number of milliseconds relative to an unspecified epoch. Typically, each stream will start with a timestamp of 0, but this is not required, as long as the two endpoints agree on the epoch. Note that this means that any synchronization across multiple streams (especially from separate hosts) requires some additional mechanism outside of RTMP. [22:36:23 CEST] <paveldimow> hmmmm [22:36:39 CEST] <BtbN> I think RTP/RTSP uses absolute global timestamps by default [22:36:47 CEST] <BtbN> meaning those streams sync themselves without any further effort [22:37:08 CEST] <BtbN> only depending on an accurtate clock on all machines involved [22:37:28 CEST] <paveldimow> would ntp be an option in that case? [22:37:33 CEST] <pgorley> do i have to set the output frame's nb_samples before calling swr_convert_frame? it's always 0 afterwards [22:37:35 CEST] <BtbN> it's required. [22:50:35 CEST] <Cracki> ntp would be a good enough option. consider gps-derived time for more precision. be aware that gps time isn't UTC time, and google time servers aren't UTC either. [23:12:01 CEST] <paveldimow> Thank you for your answers. I'll have to discuss my idea in my head few times :) [23:14:01 CEST] <paveldimow> How they did something like this? https://www.youtube.com/watch?v=xQkapLhuGV0 [23:15:36 CEST] <Cracki> timestamps I'd guess [23:15:50 CEST] <Cracki> audio and video can be bad enough to not be usable for synchronization [23:16:01 CEST] <paveldimow> :D [23:16:25 CEST] <paveldimow> you mean in this particular video from snapchat? [23:16:29 CEST] <Cracki> yes [23:16:43 CEST] <paveldimow> yes, that's make sense [23:17:15 CEST] <Cracki> perhaps even gps time, but I don't know if gps receivers typically used in smartphones give that info [23:18:22 CEST] <paveldimow> not sure [23:18:30 CEST] <paveldimow> but, what's better ntp or gps? [23:18:36 CEST] <Cracki> ntp/sntp is easy enough for them to do, and something on the order of <30 ms is imperceptible to humans [23:19:16 CEST] <Cracki> as long as you have a link, you can always to sntp/ntp. gps only works outdoors or with very good receivers. [23:19:31 CEST] <Cracki> gps would give you a very phase-stable clock signal [23:20:36 CEST] <paveldimow> thank you Cracki [23:53:31 CEST] <SpLiC3> If using ffmpeg as remuxer with avconv what commands would i need to introduce to my .json to maintain the buffer of the original .ts stream or is that a rather obtuse question? [23:54:33 CEST] <SpLiC3> source is already encoded h.264 in a .ts with acc audio, i just select copy for those though, is that correct? [00:00:00 CEST] --- Tue Aug 15 2017

1 0

ffmpeg-devel.log.20170813
by burek 14 Aug '17

14 Aug '17

[01:06:10 CEST] <cone-670> ffmpeg 03Michael Niedermayer 07master:62702eebded6: avcodec/ffv1dec_template: Fix undefined shift [01:06:10 CEST] <cone-670> ffmpeg 03Michael Niedermayer 07master:0561bd2fc2bf: avcodec/gdv: Check available space before reading palette [01:06:10 CEST] <cone-670> ffmpeg 03Michael Niedermayer 07master:5859b5b4394d: avcodec/lagarith: Detect end of input in lag_decode_line() loop [12:16:41 CEST] <BtbN> The intermediate-replacement Ryzen 1500X also has a UA number of 1707. So way in the "broken-range" [12:16:50 CEST] <BtbN> guess buying one now does not mean you're safe [12:17:11 CEST] <JEEB> ouch [12:17:24 CEST] <BtbN> well, I'm fine with my intermediate-CPU being broken in the same way [12:17:37 CEST] <BtbN> as long as my RMA gets me a properly working 1800X [12:17:47 CEST] <JEEB> true that [12:19:31 CEST] <nevcairiel> until AMD officially confirms the failure, they wont get those off the shelves. those "broken ranges" have been determined by users after all. [12:20:08 CEST] <BtbN> would have just expected them to be long sold off [12:22:04 CEST] <atomnuker> BtbN: shouldn't you cancel, now you have to RMA 2 CPUs [12:22:44 CEST] <BtbN> I haven't tested the R5 yet [12:22:53 CEST] <BtbN> it's still in its original box [12:22:58 CEST] <BtbN> won't open it until I need it [12:23:16 CEST] <BtbN> I need its plastic-packaging to re-package my CPU, as I lost the packaging for it... [12:24:02 CEST] <nevcairiel> thats why my basement is full of packaging things from all sorts of shit. i should eventually sort some of the older stuff out, but for now there is still room! =p [12:24:19 CEST] <BtbN> I still have the full packaging of the main CPU [12:24:36 CEST] <BtbN> I just lost the small piece of plastic where the actual CPU is put into, so the pins don't bend [12:24:56 CEST] <nevcairiel> that would be included in "full" in my definition =p [12:25:20 CEST] <nevcairiel> intel cpus also ship in some plastic case, i just put that back into the paper thing for storage [12:25:36 CEST] <BtbN> AMD CPUs are way more critical there than Intel though [12:26:03 CEST] <nevcairiel> i know, they still use fragile pins [12:45:40 CEST] <J_Darnley> nevcairiel: that packaging problem sounds familiar :) [17:13:14 CEST] <atomnuker> rcombs: are you going to push your flac patches finally? [20:30:59 CEST] <philipl> BtbN: We don't currently have a filter that will do a crop in cuda do we? The existing scale filters are strictly for scaling [20:31:17 CEST] <BtbN> cuvid can do cropping, but that's about it. [20:33:06 CEST] <philipl> BtbN: ah yes. But good enough for my purposes. [21:31:48 CEST] <JEEB> /30/25 [00:00:00 CEST] --- Mon Aug 14 2017

1 0

ffmpeg.log.20170813
by burek 14 Aug '17

14 Aug '17

[00:01:33 CEST] <dorvan> Peste_Bubonica: fast test... make a directory, mount a ramdisk (mount -t tmpfs tmpfs /DIR), make 2 directories inside SRC, DST, copy src in ramdisk/SRC, and convert it to ramdisk/DST and check the time. [00:01:58 CEST] <BtbN> no need for that [00:02:10 CEST] <BtbN> just use yuvtestsrc2 and output to /dev/null [00:02:14 CEST] <BtbN> if you want to benchmark purely the encoder [00:02:22 CEST] <dorvan> BtbN: it's not a need, it's a test to bypass hd I/O [00:02:52 CEST] <dorvan> if you want to benchmark only the encoder... [00:03:11 CEST] <Peste_Bubonica> dorvan, ok, I will try that [00:03:28 CEST] <dorvan> mine it's a test to check the really I/O performance of his system, making the work [00:03:31 CEST] <Cracki> disk I/O will not be the bottleneck [00:03:52 CEST] <Cracki> only uncompressed video hits the limits of currently available mass storage I/O [00:03:57 CEST] <BtbN> ffmpeg -f lavfi -i testsrc2 -c:v hevc_nvenc -pix_fmt yuv420p -f null - [00:04:03 CEST] <Cracki> ^ [00:04:07 CEST] <dorvan> Cracki: you can't say, because you don't no how is using his system [00:04:19 CEST] <Cracki> ¯\_(Ä)_/¯ [00:04:26 CEST] <BtbN> gives me ~2800fps on my 1050 here. [00:04:39 CEST] <Peste_Bubonica> beast ram # du -hs /mnt/ram/input.mkv [00:04:39 CEST] <Peste_Bubonica> 4.7G /mnt/ram/input.mkv [00:04:54 CEST] <Cracki> what resolution is testsrc2? 720x5?? ? [00:05:04 CEST] <BtbN> 320x240 by default [00:05:08 CEST] <Cracki> ic [00:05:17 CEST] <BtbN> using 1080p is probably a better test [00:05:36 CEST] <dorvan> BtbN: I confirm [00:05:38 CEST] <Cracki> linear scaling would give ~100 fps [00:05:40 CEST] <Peste_Bubonica> 4600fps [00:05:44 CEST] <Peste_Bubonica> BtbN, with your test [00:05:55 CEST] <dorvan> Peste_Bubonica: great! [00:06:11 CEST] <BtbN> 1920x1080 gives ~220 fps [00:06:27 CEST] <BtbN> ffmpeg -f lavfi -i testsrc2=size=1920x1080 -c:v hevc_nvenc -pix_fmt yuv420p -f null - [00:06:28 CEST] <Peste_Bubonica> GPU at 18% [00:06:38 CEST] <dorvan> :-) [00:06:46 CEST] <BtbN> you have to look at the video engine load. It's seperate from GPU usage [00:06:58 CEST] <Peste_Bubonica> ~390fps [00:06:59 CEST] <BtbN> Not sure if nvidia-smi even shows it. [00:07:01 CEST] <dorvan> try to change the format [00:07:11 CEST] <Peste_Bubonica> at 1920x1080 [00:07:18 CEST] <dorvan> and repeat BtbN's test [00:07:31 CEST] <Peste_Bubonica> now it goes to 400fps and become stable [00:07:41 CEST] <dorvan> good... [00:08:01 CEST] <Peste_Bubonica> i can't find it on nvidia-smi [00:08:20 CEST] <Peste_Bubonica> 57w of TDP, 22% GPU load, 53 celsius [00:08:33 CEST] <BtbN> you might have to look in nvidia-settings. Not sure if you can even read it on linux [00:08:40 CEST] <BtbN> GPUz on Windows shows it [00:09:18 CEST] <Peste_Bubonica> I have an 4k file here, 6.8GB h264 [00:09:19 CEST] <dorvan> BtbN: show only partial data [00:09:44 CEST] <Peste_Bubonica> this file don't plays well on my TV, I think that I will try to reencode it, to see if it works better [00:10:02 CEST] <Peste_Bubonica> many h265 files works well on this TV, but this h264 don't [00:10:07 CEST] <Peste_Bubonica> and it plays nice on my PC [00:10:24 CEST] <BtbN> hardware players are picky. And usually quite broken [00:10:31 CEST] <dorvan> Peste_Bubonica: check the encoder speed, but it's like a dragster test in the desert... you have to check the max perf of your system can do "really" in the city :-) [00:11:44 CEST] <dorvan> this include all the system bus transfers and bottlenecks, ramdisk can help you to remove all removable [00:11:49 CEST] <Peste_Bubonica> sorry by the noob question, but what is the difference for 10bit and 8bit? [00:12:08 CEST] <Peste_Bubonica> -pix_fmt yuv420p10 [00:12:22 CEST] <dorvan> BtbN: does not answer 2bits :-) [00:12:28 CEST] <c_14> Peste_Bubonica: 2 bits [00:12:39 CEST] <dorvan> c_14: ahahaha [00:12:44 CEST] <Peste_Bubonica> LOL [00:12:48 CEST] <c_14> Peste_Bubonica: more bits per pixel [00:13:06 CEST] <Sgeo__> Does YouTube use ffmpeg or other code to convert incoming videos? [00:13:31 CEST] <dorvan> Cracki: are you there? [00:13:56 CEST] <c_14> Peste_Bubonica: 8bit means each color channel has 255 values, 10bit has 1023 values per color channel [00:14:18 CEST] <c_14> Eh, 256 and 1024 obviously [00:14:25 CEST] <c_14> the range is 0-255 and 0-1023 [00:14:32 CEST] <JEEB> Sgeo__: they have a custom code base based on FFmpeg libraries [00:14:33 CEST] <dorvan> c_14: this seems the 10bit it's more lossless then 8bit? [00:14:39 CEST] <BtbN> Sgeo__, they are supposedly using some heavily modified, _ancient_ version of ffmpeg. [00:15:00 CEST] <Sgeo__> Oh. So it's not likely to be good at converting videos that ffmpeg chokes on? [00:15:29 CEST] <c_14> dorvan: depends on how many colors your input chip can detect, but it usually doesn't matter [00:15:37 CEST] <c_14> It just helps with quantization loss and compression [00:16:04 CEST] <dorvan> c_14: the first clear and self closing answer of the day: thanks :-) [00:26:52 CEST] <dorvan> ffserver it's alive in the ffmpeg development? [00:27:01 CEST] <BtbN> no [00:27:05 CEST] <BtbN> it's dragged along [00:27:08 CEST] <BtbN> don't use it [00:28:03 CEST] <dorvan> BtbN: thanks, I haven't used it. [00:28:19 CEST] <BtbN> nginx-rtmp is a commonly used alternative [00:28:39 CEST] <dorvan> I see.... [00:29:34 CEST] <dorvan> but I'm unsure to have another server behind the streamer... [00:30:29 CEST] <dorvan> same problem: realtime,live streaming.... with nginx-rtmp i can have an api as single source... [00:31:03 CEST] <dorvan> fragments seems are not a solution... [00:31:30 CEST] <dorvan> mjpeg can be, I searching for right params... [00:32:38 CEST] <BtbN> If you want to stream to a browser, there really is no solution for low latency [00:32:50 CEST] <BtbN> use two second segments HLS/DASH, that's the best you'll get [00:32:55 CEST] <dorvan> exactly.... [00:34:55 CEST] <dorvan> BtbN: i've already used... i can't make it works correctly, after some time video stop, or show same segments in a loop... [00:35:23 CEST] <Cracki> I haven't looked into it yet... are ffmpeg libs sufficient to write a program that generates RTP packets? [00:36:05 CEST] <Peste_Bubonica> dorvan, 70fps in a h264 to h265 yuv420p [00:36:08 CEST] <Cracki> (so, I'm interested in a custom RTP/RTSP/RTCP server/source) [00:36:08 CEST] <Peste_Bubonica> 4k [00:36:35 CEST] <dorvan> Peste_Bubonica: seems good... [00:36:57 CEST] <dorvan> Peste_Bubonica: calc Mb/s : FPs [00:37:25 CEST] <dorvan> Cracki: welcome to my problem :-) [00:37:36 CEST] <Cracki> actually no [00:37:50 CEST] <dorvan> Cracki: https://trac.ffmpeg.org/wiki/StreamingGuide#Latency but same start point :-) [00:38:14 CEST] <dorvan> Cracki: https://trac.ffmpeg.org/wiki/StreamingGuide#StreamingasimpleRTPaudiostreamf… [00:38:19 CEST] <Cracki> I'm actually interested in sticking to standards and I can control both endpoints, I don't have to mess with what browsers can do or not do [00:38:38 CEST] <dorvan> Cracki: "FFmpeg can stream a single stream using the RTP protocol. In order to avoid buffering problems ...." [00:38:40 CEST] <Cracki> but thanks for the links, that tells me ffmpeg is enough [00:39:22 CEST] <Cracki> "single stream" is bad, I'd want 1+ video and 1+ audio [00:39:35 CEST] <dorvan> exactly :-) right question, right answer..... (in that wiki there is the options to stream an mp4 :-) ) [00:43:13 CEST] <Fenrirthviti> WriteN, RTMP send error 10054 <-- anyone have a resource handy for those error codes perchance? [00:43:22 CEST] <Fenrirthviti> I used to have one, but can't for the life of me find it again [00:45:18 CEST] <Cracki> 10054 is reset by peer, iirc [00:45:22 CEST] <Cracki> windows error codes [00:45:47 CEST] <Fenrirthviti> ah, hmm. [00:52:33 CEST] <dorvan> BtbN: so how to force the refresh of segments sequence? [01:39:48 CEST] <dorvan> What about on splitting and concatenating the ffmpeg input streams to provide filter elaboration? any tips & tricks? [01:40:03 CEST] <dorvan> always for realtime/live elaboration [01:40:29 CEST] <dorvan> always for realtime/live processing* [02:38:02 CEST] <ZeroWalker> well now i can build ffmpeg with libx264, but not using msvc for some reason, it never detects libx264 [04:43:22 CEST] <Cracki> looking for hardware H.264 _decode_ performance comparisons for current amd and nvidia GPUs. anyone got links? I'm still searching [09:02:03 CEST] <m4t> hi, i'm using ffmpeg 3.3 to record an rtsp stream. it's pretty simple; -vcodec copy, and -acodec aac, since the rtsp stream is pcm_mulaw. i'm seeing occasionally the output .mp4 files will be sizeable (hundreds of MB), but fail to play (with mpv) with "[ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: moov atom not found". i can reproduce the corrupted .mp4 by doing something like 'killall -9 ffmpeg' while it's [09:02:06 CEST] <m4t> recording the rtsp stream. [09:02:31 CEST] <m4t> i'm thinking it's because ffmpeg didn't write a valid header to the stream, which the mediainfo command seems to indicate as well. [09:03:00 CEST] <m4t> is there a way to have ffmpeg periodically write a valid header mid-stream, so that if the stream suddenly dies, the video will still be mostly intact and playable? [09:04:09 CEST] <furq> use a different muxer [09:04:51 CEST] <furq> mpegts is specifically designed for this sort of thing [09:04:54 CEST] <furq> mkv should work as well [09:05:11 CEST] <m4t> furq: cool, seems simple enough [09:05:28 CEST] <m4t> currently they're shown (per file) as "ISO Media, MP4 Base Media v1 [IS0 14496-12:2003]" [09:10:04 CEST] <m4t> just changing the output from .mp4 to .m2ts seems to have done the trick. thanks furq. [09:26:35 CEST] <Cracki> m4t, incomplete mp4, if the moov atom is missing, is hard/impossible to recover. for mp4, there's a segmented/fragmented muxing mode. that helps [09:26:47 CEST] <Cracki> (if you must use mp4) [09:27:12 CEST] <Cracki> I'd go with mpeg transport streams too [09:43:21 CEST] <m4t> Cracki: thanks. i think i'm going to stick with either mkv or m2ts regardless. i noticed that i can actually get a smaller audio track by using flac instead of aac or raw pcm_mulaw. [09:43:40 CEST] <m4t> m2ts seems to be OK with flac...not sure if that's proper though [09:45:34 CEST] <m4t> actually nvm. it pretended to but mediainfo shows no audio track and mpv is silent :| [09:45:37 CEST] <m4t> mkv it is :-) [10:04:04 CEST] <Cracki> aac *can* be higher bitrate than flac, but then I'd say that was overkill [10:13:13 CEST] <m4t> i was turning the 64kbit/s 8000hz mono pcm_mulaw to -acodec aac -b:a 32k. flac seems to be ~26kbit/s [10:13:46 CEST] <m4t> ¯\_(Ä)_/¯ [10:20:01 CEST] <Cracki> omg that's very compressed [10:20:23 CEST] <Cracki> I'm not aware of ever having handled pcm_mulaw [10:24:08 CEST] <furq> it's usually used for speech [10:24:08 CEST] <Cracki> oh if you're compressing speech, play with opus [10:24:08 CEST] <furq> you could probably use 8kbps aac or something [10:24:08 CEST] <furq> but at that bitrate you might as well just use flac [10:24:14 CEST] <Cracki> aye [10:24:30 CEST] <m4t> i might play with opus. i'd rather have it lossless tbh though. [10:24:41 CEST] <m4t> it sounds crappy enough as it is :| [10:24:42 CEST] <furq> yeah there's not much point going from 26kbps to 6kbps [10:25:09 CEST] <furq> or however low opus will go for 8khz mono [10:26:54 CEST] <Cracki> if the source is 8khz 8bit mulaw... ¯\_(Ä)_/¯ [10:26:54 CEST] <m4t> yep [10:26:54 CEST] <Cracki> more bits for the video [10:27:06 CEST] <furq> he's copying the video stream anyway [10:27:44 CEST] <m4t> unrelated, is anyone familiar with a *cheap* way to do h.264 -> h.265 transcoding in real time? i spent many hours looking at the specs of all the raspberry pi like boards, and a bunch of barebones cameras etc. from aliexpress. couldn't come up with anything that seemed suitable. [10:28:03 CEST] <Cracki> I have this image in my head of an elephant and a mouse being squeezed in a box and they together take the cube shape [10:28:15 CEST] <furq> there's certainly nothing that'll do it well [10:28:16 CEST] <Cracki> how cheap? [10:28:16 CEST] <m4t> some of the chips *did* have h.265 hw encode, but the sdk is under nda and/or unusable [10:28:31 CEST] <m4t> i dunno. like < $50 [10:28:32 CEST] <Cracki> repacking quantized coefficients maybe [10:28:40 CEST] <furq> there's definitely nothing that will actually reduce the bitrate and keep the same quality [10:28:46 CEST] <furq> unless your h264 encoder is really awful [10:29:15 CEST] <Cracki> why even transcode to 265? [10:29:23 CEST] <m4t> limited bandwidth [10:29:30 CEST] <m4t> & disk space [10:29:42 CEST] <Cracki> that's only gonna save you half the data rate, or give you better quality [10:29:46 CEST] <furq> x264 will outperform all of the consumer hevc hardware encoders [10:29:50 CEST] <Cracki> ^ [10:29:58 CEST] <furq> it's much better than nvenc hevc, which is one of the better ones [10:30:18 CEST] <m4t> x265 you mean? [10:30:21 CEST] <furq> no i mean x264 [10:30:25 CEST] <m4t> oh [10:30:47 CEST] <m4t> when you say outperform, you mean quality per bitrate? really? [10:30:50 CEST] <furq> yeah [10:30:52 CEST] <m4t> hah [10:30:53 CEST] <Cracki> recent graphics cards have hevc encode in hw that's supposed to be realtime for 2-4k res [10:31:05 CEST] <furq> bear in mind this is x264, not any other h264 encoder [10:31:35 CEST] <furq> but if you're thinking about credit card sized boards, the hw encoding on those is generally awful [10:31:38 CEST] <m4t> i don't really know enough about the subject, just the marketing of h.265 being same quality in half the bitrate [10:31:45 CEST] <m4t> which apparently is more hype than truth [10:31:50 CEST] <m4t> yeah... [10:31:54 CEST] <furq> well it's somewhat true if you compare the reference encoders [10:31:56 CEST] <Cracki> it's *possible* with hevc [10:32:07 CEST] <Cracki> but it requires lots of crunch during encode [10:32:08 CEST] <m4t> and, there is likely no out of the box transcoding utility that can handle an rtsp stream, like i need to [10:32:09 CEST] <furq> but the reference encoders are a very long way from the state of the art [10:32:30 CEST] <furq> and also the gap is necessarily less if you have realtime constraints [10:33:05 CEST] <Cracki> afaik the raspi has h.264 hw encode, but I'm not aware of 265 ip being in there [10:33:12 CEST] <furq> at the same encoding speed, x264 is roughly as good as x265 [10:33:28 CEST] <furq> x265 only pulls out in front when it's running slower than x264 -preset veryslow [10:33:29 CEST] <Cracki> :P 265 is a kind of superset of 264 [10:33:55 CEST] <Cracki> larger allowed blocks and such [10:34:36 CEST] <Cracki> I wonder when they'll just encode optical flow pyramids rather than blocks of a limited size... [10:35:29 CEST] <furq> also yeah the pi doesn't do hevc encode [10:35:38 CEST] <furq> but if it did it would probably be terrible [10:35:45 CEST] <furq> the avc encoder is barely better than a joke [10:35:53 CEST] <bencoh> it's better off without it yeah [10:36:07 CEST] <m4t> a lot of the newer android set top boxes coming out of china have soc's with hevc encode [10:36:15 CEST] <bencoh> people would start using otherwise :p [10:36:16 CEST] <m4t> but without an sdk or utility it's worthless to me [10:36:26 CEST] <Cracki> a bunch of single board computers also gained hevc encode... [10:36:42 CEST] <Cracki> it's added to a lot of arm cortex A processors [10:36:44 CEST] <furq> i wouldn't worry too much about it [10:36:47 CEST] <m4t> hmm do you know of any off the top of your head? it was several months ago when i looked into this [10:36:56 CEST] <Cracki> all the mobile phone stuff wants it [10:36:59 CEST] <furq> that kind of thing generally just does the bare minimum to create some kind of hevc compliant bitstream [10:37:06 CEST] <m4t> yea [10:37:10 CEST] <Cracki> I was searching the net just now [10:37:12 CEST] <Cracki> nothing conclusive [10:37:20 CEST] <furq> it won't come close to what a well-optimised encoder can do [10:37:41 CEST] <Cracki> decoders are trivial. encoders... silicon is hard. [10:37:43 CEST] <m4t> i bet the ambarella chips are decent. https://www.ambarella.com/news/105/122/Ambarella-Introduces-H22-a-4K-Ultra-… [10:37:45 CEST] <bencoh> just like h264 back 5~7 years ago [10:37:48 CEST] <BtbN> nvenc is probably near the top-end of hardware encoders [10:37:51 CEST] <BtbN> and it's still bad [10:37:58 CEST] <m4t> those are what's in the gopro iirc [10:38:04 CEST] <furq> yeah and nvenc hevc is barely better than nvenc h264 [10:38:09 CEST] <Cracki> hw-accelerated compression is an option [10:38:14 CEST] <m4t> (well, same brand) [10:38:19 CEST] <Cracki> hw does the motion estimation, sw uses that [10:38:36 CEST] <Cracki> a large part of the cpu time is spent on ME [10:39:31 CEST] <Cracki> companies like mainconcept make codecs for video production and those are gpu (opencl?) accelerated [10:40:07 CEST] <BtbN> GPUs are generally pretty useless for video encoding [10:40:52 CEST] <Cracki> well they're massively parallel and can do the ME part [10:41:14 CEST] <Cracki> not saying to use the fixed function encoders [10:41:56 CEST] <m4t> what does ME stand for? [10:42:05 CEST] <furq> motion estimation [10:42:15 CEST] <BtbN> Isn't that what x264 uses opencl for? It's useless there as well, and sometimes even slower/worse quality. [10:42:19 CEST] <m4t> oh ok, thx [10:43:17 CEST] <Cracki> x264 doesn't use opencl at all [10:43:18 CEST] <Cracki> afaik [10:43:25 CEST] <bencoh> there was a project [10:43:32 CEST] <furq> it can use it for lookahead [10:43:36 CEST] <Cracki> dealing with gpus means dealing with latency during the transfer. [10:43:41 CEST] <Cracki> gpu programming is no magic bullet. [10:43:44 CEST] <bencoh> I'm not sure it has been merged (?) [10:43:50 CEST] <Cracki> it has to be worth it to move data off-ram [10:43:56 CEST] <furq> opencl lookahead has been upstream for ages [10:44:00 CEST] <bencoh> ah [10:44:13 CEST] <furq> there was a gsoc project ages ago for opencl ME [10:44:20 CEST] <furq> i don't think that ever made it though [10:44:33 CEST] <Cracki> if you have an integrated GPU, one that shares main memory, it can be lots faster for small operations [10:44:44 CEST] <Cracki> ME isn't trivial [10:45:12 CEST] <furq> i'm happy enough just using my gpu for denoising [10:45:21 CEST] <Cracki> and imho way out of most gsoc's applicants' competence [10:45:34 CEST] <Cracki> basically optical flow. [10:45:48 CEST] <Cracki> typical encoders seem to be doing block matching. [10:46:02 CEST] <Cracki> on a single scale. [10:47:03 CEST] <Cracki> if you throw state of the art optical flow estimation algorithms at it, you get quite good results and you can use those trivially for video compression [10:47:19 CEST] <Cracki> even shit algos are good enough for video compression [10:50:55 CEST] <Cracki> ah so lookahead is supposed to compute a downscaled version of input frames? [10:53:10 CEST] <m4t> Cracki: btw out of curiousity i just looked into -help muxer=mp4 and tried the original .mp4 but with '-movflags frag_keyframe'. seems to immediately write a header and kill -9'ing it results in a watchable video. but i like mkv+flac better anyways... [10:53:25 CEST] <Cracki> ^^ [10:53:31 CEST] <furq> afaik lookahead does a low-resolution encode and uses that to determine how many bframes to use [10:53:39 CEST] <BtbN> fragmented mp4 doesn't have the most widespread support [10:53:43 CEST] <Cracki> it's just something we use for screencaptures that get killed abruptly [10:54:05 CEST] <furq> and yeah fmp4 is a hack to allow streaming mp4 to browsers [10:54:31 CEST] <furq> because it was easier than getting browsers to add one of the many existing formats which does the same thing [10:54:36 CEST] <furq> because browser vendors are subhuman scum [10:54:39 CEST] <Cracki> we're stuffing qtrle+aac in a mov container... [10:55:07 CEST] <Cracki> any better option for lossless rgb888 that compresses synthetic video quite well? [10:55:16 CEST] <furq> ffv1? [10:55:37 CEST] <Cracki> how stable and fast is it? qtrle is dumb as heck and thus quite fast [10:55:49 CEST] <furq> it's very stable [10:55:57 CEST] <furq> you'll have to find out how fast it is [10:55:59 CEST] <Cracki> oh also it should be readable by adobe premiere :P [10:56:02 CEST] <furq> oh [10:56:07 CEST] <Cracki> *g* yeah [10:56:13 CEST] <furq> yeah that was worth mentioning up front [10:56:20 CEST] <furq> there's no dshow or quicktime components for ffv1 afaik [10:56:26 CEST] <furq> the best thing that does have those is probably ut video [10:56:41 CEST] <Cracki> it can read qtrle using quicktime codecs, it's supposed to read everything Windows knows in terms of installed codecs... but who knows [10:57:08 CEST] <furq> "everything windows knows" is dshow [10:57:23 CEST] <Cracki> i've used lagarith for a while but then I read someone claim the floating point math makes it not quite lossless or unpredictable [10:57:35 CEST] <Cracki> yes vfw/dshow/media foundation [10:57:42 CEST] <Cracki> depending on what api premiere knows :P [10:57:54 CEST] <furq> utvideo should work anyway [10:57:57 CEST] <furq> and utvideo is very fast [10:58:05 CEST] <furq> but it's not as good as ffv1 in my experience [10:58:07 CEST] <Cracki> hmhm gotta try that [10:58:26 CEST] <Cracki> I'm really looking for lossless non-subsampled non-colorspace-converted if possible [10:58:48 CEST] <Cracki> ut video, ah good [10:58:54 CEST] <furq> utvideo and ffv1 both do rgb24 [10:58:54 CEST] <Cracki> says it does what I want [10:59:03 CEST] <furq> x264 lossless will do it as well [10:59:09 CEST] <furq> although the compression isn't amazing in rgb iirc [10:59:28 CEST] <Cracki> h.264 in anything other than yuv420 will choke (older) premiere [10:59:45 CEST] <Cracki> and my folks cba to pay for monthly/yearly subscriptions [10:59:56 CEST] <furq> these are all general-purpose codecs, so qtrle might smash them all if you have a source that it does well on [11:00:07 CEST] <Cracki> something about "owning" software that's obsolete a year after you bought it [11:00:28 CEST] <Cracki> qtrle explodes if you give it "sensor data" [11:00:32 CEST] <Cracki> it's just RLE after all [11:00:50 CEST] <furq> yeah qtrle is generally either amazingly good or unusable [11:00:51 CEST] <Cracki> so sometimes we knowingly use x264 444 lossless [11:01:28 CEST] <furq> ffv1 is the best general-purpose lossless codec in my experience, but obviously the compatibility is an issue [11:01:35 CEST] <furq> someone should really just make qt/dshow components for it [11:01:36 CEST] <Cracki> is the qtrle codec in ffmpeg optimized much? I was thinking maybe it'd benefit from some love [11:01:40 CEST] <furq> no idea [11:01:44 CEST] <Cracki> hm ok [11:01:56 CEST] <Cracki> maybe I should bother someone to wrap ffv1 into a dshow filter [11:01:58 CEST] <furq> it doesn't seem like there's a huge amount there to optimise [11:02:12 CEST] <Cracki> well, you can parallelize encoding of rows [11:02:53 CEST] <Cracki> since it just does rle and compares to the previous frame, this could even be sent to opencl... but again, latency, likely not worth it [11:03:15 CEST] <furq> i guess it would benefit from frame threading if it doesn't already have it [11:03:19 CEST] <Cracki> loop autovectorization or a bunch of arcane intrinsics probably do better [11:03:33 CEST] <Cracki> afaik it doesn't do frame threading. [11:03:35 CEST] <furq> Threading capabilities: none [11:03:36 CEST] <furq> fun [11:03:39 CEST] <dorvan> hi all [11:03:41 CEST] <furq> yeah i guess that's an easy win then [11:03:51 CEST] <Cracki> heh ok maybe I should look into that then [11:05:04 CEST] <Cracki> qtrle doesn't have a notion of keyframes, at least not a flag for it. a frame could update all pixels, or none, and you'll only know after at least superficially decoding the frame. [11:05:12 CEST] <furq> i assume using shotcut or some other NLE that uses ffmpeg's codecs is out of the question [11:05:20 CEST] <Cracki> mostly [11:05:45 CEST] <Cracki> it's either premiere or hardcoding all we do in a custom program [11:06:32 CEST] <Cracki> it's bad enough premiere up to recently had really bad color correction facilities. [11:06:47 CEST] <Cracki> physically incorrect ones even. [11:06:53 CEST] <furq> nice [11:07:04 CEST] <Cracki> the lumetri stuff works correctly. [11:07:28 CEST] <Cracki> what the old stuff did was work in yuv (ok so far) but added a fixed uv to everything, irrespective of y [11:07:41 CEST] <Cracki> so black gets turned into *strongly hued* black [11:08:24 CEST] <Cracki> so the way to avoid that was ignore the color correctors and tweak gains in a levels/curves filter [11:08:42 CEST] <dorvan> Cracki: when you have time, i need to discuss something with you about concatenate many ffmpeg processes for filtering [11:09:00 CEST] <Cracki> no, discuss that with the channel. [11:09:07 CEST] <dorvan> Cracki: if you are available [11:09:18 CEST] <dorvan> Cracki: thanks :-) [11:09:19 CEST] <Cracki> I am unavailable. [11:09:42 CEST] <Cracki> I'm deeply averse to being asked things personally that have nothing to do with me. [11:09:48 CEST] <dorvan> Cracki: thanks :-) [11:16:42 CEST] <dorvan> hi all, I need to concatenate many ffmpeg processes for filtering from a realtime/live source (rtmp) (level1), and then output stream to a web streamable format (level2). between level1 and level2 I need to use the stream with opencv or with a neural network software for object detection, face recognition. I'm evaluating the process structure to be more "realtime as possible" [11:17:04 CEST] <dorvan> thanks for help. [11:18:01 CEST] <Cracki> ah now I know why I discarded all those other lossless codecs... they have insane bitrates, or I don't know what to tweak... [11:22:15 CEST] <Cracki> so utvideo (and huvyuv) don't suit me because they encode intra-only. my videos rarely change at all, they're screen caps of powerpoint karaoke. I need either null frames (absolutely no change) or p-frames. qtrle and lagarith can do that, if I tell them to. [11:25:34 CEST] <furq> yeah ffv1 will do much better on that [11:25:51 CEST] <furq> but if it's screen captures then qtrle will probably still beat it [11:26:52 CEST] <Cracki> ugh... if someone's willing to pay me for work on qtrle, I'm game. otherwise I'll maybe get to it eventually maybe... maybe [11:28:41 CEST] <Cracki> I think I'll have to kick my people to upgrade premiere. they need to using H.264 4:4;4 [11:37:18 CEST] <furq> apparently ffv1 will work in premiere on windows through lav filters [11:37:41 CEST] <furq> and i found some quicktime component that does the same thing but it seems to be discontinued now [11:37:48 CEST] <furq> http://perian.org/#download [11:39:18 CEST] <Cracki> yay [11:40:40 CEST] <Cracki> lots of what's in the trac wiki might have a better place in the actual docs [11:40:47 CEST] <Cracki> such as https://trac.ffmpeg.org/wiki/Encode/FFV1 [11:42:11 CEST] <JEEB> furq: perian is discontinued and you should take a look at how the Ut Video guy makes components [11:42:43 CEST] <JEEB> since he made components for all of the major multimedia frameworks [11:43:50 CEST] <JEEB> if FFV1 had something similar I could be recommending it to the NLE people. unfortunately currently that's not the case :/ [11:44:06 CEST] <JEEB> also a lot of editors still seem to be utilizing VFW (or moved to MF) so I'm surprised LAV can be used in some cases [11:45:25 CEST] <ritsuka> quicktime is discontinued too, and the replacement doesn't have a public api for video components yet. But I guess premiere on mac might still use the old quicktime framework [11:45:46 CEST] <JEEB> yes, everything is atm using the QT stuff [11:45:50 CEST] <JEEB> on MacOS [11:46:05 CEST] <ritsuka> mm no, final cut x doesn't for example [11:46:08 CEST] <bencoh> QT is discontinued? ohmy [11:46:17 CEST] <JEEB> bencoh: like VFW is discontinued :D [11:46:25 CEST] <JEEB> ritsuka: so it has completely its own stuff [11:46:29 CEST] <JEEB> even for export? [11:46:31 CEST] <bencoh> uhuh [11:46:40 CEST] <ritsuka> it uses avfoundation/videotoolbox/coremedia and friends [11:47:03 CEST] <ritsuka> but there isn't a public api for videotoolbox components [11:50:34 CEST] <Cracki> btw, ffv1 doesn't seem to react to -g... bit rate stays the same with -g 0, 1 or 100, even for static video content... [11:50:48 CEST] <Cracki> (about 15 Mbps for 1280x960 input) [12:42:20 CEST] <ZeroWalker> what's zlib used for in ffmpeg? [12:43:30 CEST] <JEEB> zlib is used for png encoding I think? among some other minor things [12:43:56 CEST] <JEEB> z.lib (commonly known as zimg) is used for a scaling/colorspace conversion filter [12:50:18 CEST] <ZeroWalker> wait so does zimg use zlib, why would that be needed for scaling/converting colorspaces? [12:52:00 CEST] <furq> no [12:52:04 CEST] <JEEB> the author of zimg is a known troll, the "official name" of the library is z-dot-lib [12:52:07 CEST] <JEEB> because of course [12:52:10 CEST] <furq> zimg is actually called "z.lib" because the guy who made it is some kind of ratfucker [12:52:19 CEST] <furq> but nobody calls it that because of course they don't [12:52:40 CEST] <furq> the actual zlib is used for png, yeah [12:52:43 CEST] <JEEB> yup [12:52:56 CEST] <JEEB> there might have been some other things it was used in, but png encoding is the one I noticed [12:53:12 CEST] <furq> yeah i've seen a few people with builds that can't encode png because of no zlib [12:54:35 CEST] <JEEB> well to be honest even the pkg-config file is "zimg" https://github.com/sekrit-twc/zimg/blob/master/zimg.pc.in [12:54:53 CEST] <JEEB> so it's not that bad, he did understand that if he made his library called "z" it would be a bit too much of a troll :P [12:54:56 CEST] <furq> yeah i think even he realised calling it z.lib outside of the github readme was a real shit idea [13:16:34 CEST] <ZeroWalker> how can you link libopus statically [13:16:51 CEST] <BtbN> build a static version of it and use it [13:18:01 CEST] <ZeroWalker> i did --enable-static on libopus configure, guess that wasn't the command [13:21:07 CEST] <BtbN> If the shared libs are still there, they will be prefered. [13:21:31 CEST] <ZeroWalker> ah [13:21:31 CEST] <BtbN> You might be able to do some magic with pkg-config, by forcing it to return the static version [13:21:58 CEST] <ZeroWalker> well never got pkg-config to work so i use extra flags to specify the locations [13:22:20 CEST] <BtbN> configure requires pkg-config for a lot of things. [13:22:39 CEST] <ZeroWalker> but i will clear the libopus, that was probably the issue, think i had the same with libx264, it required the dll for some reason, but i think after clearing and remaking it it works [13:22:54 CEST] <ZeroWalker> well i have it, but i mean, it doesn't auto detect libx264 etc [13:37:00 CEST] <furq> ZeroWalker: --extra-ldflags="-static" [13:37:07 CEST] <furq> will tell the linker to prefer static libs [13:37:47 CEST] <furq> you'll probably need --pkg-config-flags="--static" as well [13:54:54 CEST] <bencoh> err, -static isn't just a "preference" (?) [14:44:30 CEST] <dystopia_> how come i loose the subtitles when catting vobs together with -copy ? [14:44:45 CEST] <dystopia_> ffmpeg.exe -i "concat:VTS_01_1.VOB|VTS_01_2.VOB|VTS_01_3.VOB|VTS_01_4.VOB|VTS_01_5.VOB|VTS_01_6.VOB" -c copy movie.vob [14:45:03 CEST] <dystopia_> each vob has subs before concat, output does not [14:46:13 CEST] <JEEB> I think you're putting a bit too much expectations on the workings of the concat features that come before decoding [14:46:21 CEST] <JEEB> but you can open a bug report on the trac if you want [14:46:41 CEST] <dystopia_> nah it's not a big deal, i just thought maybe i did somthing wrong [14:47:12 CEST] <furq> dystopia_: you probably want to use tccat for that [14:47:43 CEST] <JEEB> I don't remember if MPEG-PS could be just concatenated like MPEG-TS [14:48:00 CEST] <dystopia_> ok i will give tccat a go [14:48:09 CEST] <JEEB> (VOBs are MPEG-PS) [14:48:16 CEST] <dystopia_> hmm [14:48:36 CEST] <furq> i'm pretty sure it'll work with ffmpeg if you bump analyzeduration/probesize [14:48:44 CEST] <dystopia_> basically i want to encode the dvd to x264 with subs, maybe i don't need to cat, i can just encode the vobs, then merge them at the end [14:48:50 CEST] <furq> subtitle streams often don't show up within the first 5MB [14:48:59 CEST] <furq> but honestly, if you're working with dvds at all then you want to use tccat [14:49:06 CEST] <furq> and/or tcdemux [15:27:15 CEST] <nikon> Hello [15:27:19 CEST] <nikon> anyone can help me? [15:29:05 CEST] <nikon> i'm trying stream with http to rtmp and i get this error all time [15:29:06 CEST] <nikon> av_interleaved_write_frame(): Broken pipeB time=00:00:25.44 bitrate=1192.6kbits/s [flv @ 0xc35680] Failed to update header with correct duration. [flv @ 0xc35680] Failed to update header with correct filesize. [15:29:10 CEST] <nikon> anyone know why? [15:30:42 CEST] <BtbN> you're writing it somewhere that's not seekable. [15:31:00 CEST] <BtbN> and "with http to rtmp" makes no sense [15:32:08 CEST] <nikon> how so? [15:32:20 CEST] <nikon> i'm trying to restream from http to rtmp using this command [15:32:46 CEST] <nikon> screen ffmpeg -i "http://serveronline.io:6969/live/user01/Y1pktR5KiP/7051.ts" -async 30 -c:v libx264 -preset veryfast -ab 64k -ar 11025 -ac 2 -c:a aac -strict experimental -s 640x360 -r 30 -vb 1200k -f flv "rtmp://up.widestream.io/wideorigin?token=kqznfic/lafbm6j" [15:32:56 CEST] <nikon> and they work but after some seconds process close [15:33:06 CEST] <nikon> and i see this error in ssh [15:33:12 CEST] <nikon> av_interleaved_write_frame(): Broken pipeB time=00:00:25.44 bitrate=1192.6kbits/s [flv @ 0xc35680] Failed to update header with correct duration. [flv @ 0xc35680] Failed to update header with correct filesize. [15:33:37 CEST] <furq> you probably want to change your rtmp token [15:34:40 CEST] <nikon> furq why? [15:34:52 CEST] <BtbN> Because you just pasted it here. [15:34:54 CEST] <furq> because you just pasted it in a public irc channel [15:35:16 CEST] <furq> also if you still need -strict experimental then you're on an old ffmpeg [15:35:31 CEST] <BtbN> "Broken Pipe" also indicates a network issue [15:35:44 CEST] <nikon> what type of issue? [15:35:54 CEST] <nikon> no upstream avaliable? [15:35:59 CEST] <furq> it usually means the connection was closed [15:36:20 CEST] <nikon> [14:35] <furq> also if you still need -strict experimental then you're on an old ffmpeg [15:36:29 CEST] <nikon> yes i have oldest version of ffmpeg [15:36:35 CEST] <nikon> i don't know how to update [15:36:51 CEST] <furq> if your distro ffmpeg is old then https://www.johnvansickle.com/ffmpeg/ [15:37:19 CEST] <furq> it's worth upgrading anyway because the builtin aac encoder is massively improved in 3.x [15:38:02 CEST] <nikon> i'm not a linux expert can you please help me update my ffmpeg? [15:38:11 CEST] <nikon> [root@ns345064 ~]# ffmpeg ffmpeg version 2.6.8 Copyright (c) 2000-2016 the FFmpeg developers built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-4) [15:38:13 CEST] <nikon> this is my version [15:38:14 CEST] <furq> download that and put the binaries in /usr/local/bin [15:38:25 CEST] <BtbN> Or just use it from whereever [15:38:38 CEST] <furq> also stop running as root [15:39:07 CEST] <nikon> download x86_64 build: ffmpeg-git-64bit-static.tar.xz - md5 ? for /usr/local/bin folder? [15:39:42 CEST] <furq> ? [15:40:23 CEST] <nikon> [14:38] <furq> download that and put the binaries in /usr/local/bin [15:40:29 CEST] <nikon> i don't understand what i need to do [15:40:42 CEST] <furq> tar xvf ffmpeg-git-64bit-static.tar.xz [15:41:04 CEST] <nikon> ok, and now? [15:41:04 CEST] <furq> will give you a directory with ffmpeg, ffprobe etc binaries [15:41:21 CEST] <nikon> yes [15:41:26 CEST] <furq> either call them directly or move them into /usr/local/bin and delete your distro's ffmpeg package [15:41:27 CEST] <nikon> https://i.gyazo.com/8cac984de818d512f6ed6d4c5b47f968.png [15:41:58 CEST] <nikon> "delete your distro's ffmpeg package" [15:42:02 CEST] <nikon> how can i do this? [15:42:38 CEST] <JEEB> just call your ffmpeg directly [15:42:38 CEST] <nikon> yum remove ffmpeg ? [15:42:49 CEST] <furq> probably [15:42:51 CEST] <nikon> how? like ./ffmpeg ? [15:42:54 CEST] <furq> i haven't used centos in 10+ years [15:42:57 CEST] <JEEB> or full path [15:43:04 CEST] <furq> and yeah you can just call it directly [15:43:07 CEST] <JEEB> if you're in the same directory then ./ffmpeg will work [15:43:10 CEST] <furq> or put it in ~/bin or something [15:43:13 CEST] <nikon> ok [15:43:16 CEST] <nikon> let me try [15:43:17 CEST] <furq> idk if that's in the path on centos, especially not if you're logged in as root [15:48:35 CEST] <nikon> I definitely do not understand any of this, I'm going to have to look for some expert, does anyone here give paid support about it? [20:33:52 CEST] <cryptodechange> Been playing with the nlmeans feature to reduce grain, where it's reduced the grain and kept the quality, it has kind of made a heat distortion/mirage effect on backgrounds [20:34:11 CEST] <cryptodechange> I suppose it's the frame shaking but is hidden by the grain itself [20:48:11 CEST] <cryptodechange> https://imgur.com/a/jCamo [00:00:00 CEST] --- Mon Aug 14 2017

1 0

ffmpeg-devel.log.20170812
by burek 13 Aug '17

13 Aug '17

[00:21:43 CEST] <ars> Hello guys. I have problem. error while loading shared libraries: libva.so.1: cannot open shared object file: No such file or directory. Looks like it not linked statically. But i compile like: configure --enable-libmfx --enable-nonfree --enable-gpl --disable-shared --enable-static [00:23:18 CEST] <nevcairiel> those options controls what kind of ffmpeg libraries you build, not how things are linked in [00:24:45 CEST] <ars> nevcairiel, how can make static build ? [00:25:09 CEST] <nevcairiel> static linking against libva is probably generally not possible [00:25:39 CEST] <ars> :( ooo, thank you [11:13:46 CEST] <ZeroWalker> trying to understand Bicubic, if i get things right, cubic means that it samples all the surrounding pixels of a a pixel, merge the values with that pixel, but there's a weight parameter that tells how much that center pixel should be prioritized [11:17:26 CEST] <nevcairiel> simplified, cubic means it samples two data points in every direction, and bicubic means it does that in 2 dimensions (for 16 data points in total) [11:18:36 CEST] <ZeroWalker> so it's a "cross" + , not every surrounding pixel "square"? [11:19:20 CEST] <ZeroWalker> at least if i get every direction correctly. (x and y) [11:19:46 CEST] <nevcairiel> for bicubic you take the 4x4 pixel grid around your desired point [11:20:23 CEST] <ZeroWalker> hmm [11:21:25 CEST] <ZeroWalker> feels a bit weird, so, if you don't have 4x4 pixels (near the edge), does it just make do with that it has? [11:22:47 CEST] <nevcairiel> typical approach is just to just extend the edge (or clamp the index, but thats the same result different implementation), so you just pretend that the last pixel row/col extends like that outwards [11:23:23 CEST] <ZeroWalker> ah [11:24:47 CEST] <ZeroWalker> hmm, but confused that it's 4x4, does it affect 4 pixels accordingly to the surrounding ones, or is it 1 pixels that's affected by all of those:s [11:25:52 CEST] <nevcairiel> one pixel is created based on those 16 pixel [11:26:04 CEST] <nevcairiel> with proper weighting based on its position, of course [11:27:28 CEST] <ZeroWalker> okay then i get that part. hmm, didn't know the weightning was based on the position, thought it was constant, like "value the original pixel 75% and have 25% of the surrounding samples" or something [11:32:54 CEST] <nevcairiel> what if you dont hit the position of an original pixel [11:33:38 CEST] <nevcairiel> if you upscale by a variable factor, the grids wont match up [11:34:01 CEST] <ZeroWalker> ah yeah was thinking about that [11:34:57 CEST] <nevcairiel> if you do something simple like doubling the size, then stuff gets easier [11:43:22 CEST] <ZeroWalker> yeah, hmm, where i am interested it's mostly varying [12:53:06 CEST] <BtbN> I actually did a BIOS reset to default values. Still crashing. So it's not my RAM "OC" or anything I played around with too much [12:53:14 CEST] <BtbN> now waiting for AMD to reply to me asking for a new CPU [13:01:22 CEST] <wm4> just go and pick some intel GPU from a heap of discarded old computers /troll [13:01:27 CEST] <wm4> *CPU [13:04:49 CEST] <BtbN> Intel has nothing that remotely compares [13:05:13 CEST] <BtbN> And Intel also had bad day-one batches of CPUs [13:05:16 CEST] <BtbN> Broadwell was a disaster [13:05:20 CEST] <wm4> I'm sure they do for $$$ [13:05:40 CEST] <BtbN> I won't pay 3x the money for a similar CPU from Intel, which then also uses twice as much power [13:05:44 CEST] <wm4> but yeah Intel seems to be dropping the ball [13:06:04 CEST] <BtbN> The i9 CPUs are a disaster [13:06:11 CEST] <BtbN> if you want to actually use them, you are forced to delid them [13:06:35 CEST] <BtbN> Threadripper is going to steamroll them in that segment [13:07:03 CEST] <nevcairiel> thats not really a big problem if there is shops that sell them delidded with 2 year warranty =p [13:07:10 CEST] <BtbN> for 1000$ you either get 10 overheating Intel cores, or 16 actually working Threadripper cores [13:07:35 CEST] <BtbN> It just boggles my mind that intel cheaps out on soldering on the lid for a 1k$ CPU [13:09:42 CEST] <wm4> CPUs have a lid? [13:13:14 CEST] <J_Darnley> The metal heatspreader that is stuck over the bare silicon [13:14:13 CEST] <J_Darnley> BtbN: Do you use unbuffered ECC ram with your Ryzen? (A question unrelated to the crashing issues) [13:14:42 CEST] <BtbN> My mainboard does not support ECC anyway [13:14:49 CEST] <BtbN> It's not a RAM issue [13:15:15 CEST] <BtbN> I can run the Prime95 RAM-Test for a full day, and it's perfectly happy [13:15:23 CEST] <J_Darnley> I know. It wasn't supposed to be related to the crashing issue [13:15:36 CEST] <BtbN> but building gcc for a few minutes throws segfaults and invalid opcodes left and right [13:15:39 CEST] <J_Darnley> I just wanted to know [13:16:02 CEST] <BtbN> I heard reports of ECC actually working though [13:16:10 CEST] <BtbN> but there is no fast ECC ram, and i don't overly care [13:16:23 CEST] <BtbN> Ryzen really profits from running RAM at high clock rates [13:16:31 CEST] <J_Darnley> Yes, there are sporadic reports from users and some talk of support from AMD. [13:16:41 CEST] <BtbN> Ryzen does support ECC [13:16:46 CEST] <BtbN> it just comes down to the mainboard [13:16:57 CEST] <BtbN> There are some that actually support it [13:17:07 CEST] <J_Darnley> A few motherboards claim to support ECC orr atleast a couple of ECC ram products [13:17:24 CEST] <BtbN> you always have ECC for the CPU caches though, which is super nice [13:28:59 CEST] <durandal_1707> how do one frame accurate seek with lavf? [13:30:47 CEST] <nevcairiel> you dont [13:32:47 CEST] <durandal_1707> nevcairiel: thats not very helpful [13:32:56 CEST] <nevcairiel> but the truth [13:33:17 CEST] <nevcairiel> lavf is not setup for that [13:33:28 CEST] <durandal_1707> but mpv can [13:33:52 CEST] <ubitux> you set the seek time and upper boundary to the ts, the lower to 0 (or intmin?) [13:33:57 CEST] <ubitux> then you decode til your reach the ts [13:34:35 CEST] <ubitux> (and then someone will tell you it won't work in case X, Y and Z at least) [13:35:26 CEST] <ubitux> avformat_seek_file(ctx->fmt_ctx, -1, INT64_MIN, seek_to, seek_to, 0); [13:35:29 CEST] <ubitux> i'm using this [13:35:44 CEST] <ubitux> and decode til expected [13:37:51 CEST] <wm4> accurate seek obviously requires you to skip decoded frames too until the target timestamp [13:37:57 CEST] <wm4> also that seek API sucks [14:21:25 CEST] <durandal_1707> how one can convert from pts to frame number? [14:57:52 CEST] <BtbN> There's no direct conversion [14:57:58 CEST] <BtbN> only way to get frame number is to actually count [15:07:40 CEST] <djgl> Hi, I noticed that the libswscale yuv2rgb routines on x86 need stride/8 >= (width+7)/8. Otherwise they will drop pixels on the right. What is a safe stride value across all architectures? [15:11:10 CEST] <jkqxz> The av_malloc alignment will always be sufficient. [15:11:35 CEST] <atomnuker> BtbN: didn't you already order a new CPU? [15:12:21 CEST] <djgl> jkqxz, it's not about the alignment of the buffer. It's about having more space than needed for the pixels in a line. [15:13:03 CEST] <wm4> libav has a function to get the required alignment [15:13:09 CEST] <wm4> not sure if it got ported to ffmpeg [15:13:25 CEST] <jkqxz> For this purpose they are the same thing. [15:14:14 CEST] <BtbN> atomnuker, a cheap intermediate-one [15:14:21 CEST] <wm4> yeah, basically every first pixel of a line has to have the minimum alignment [15:14:35 CEST] <wm4> which is normally achieved by aligning the start pointer and the line size [15:14:47 CEST] <BtbN> I need a working PC. Not going to send them my CPU and then just not have a working PC for a month or however long they take [15:15:04 CEST] <wm4> hardware problems suck [15:15:08 CEST] <iive> BtbN: have you talked to the shop? [15:16:19 CEST] <djgl> But it's not documented which alignment to use. The doc/examples/scaling_video.c example does it wrong and uses av_image_alloc(..., 1) for the output frame. [15:16:56 CEST] <BtbN> iive, yes, but they have no idea about the issue at hand, and would probably just grab another random CPU off the shelf. [15:17:05 CEST] <BtbN> And it would take way longer with them [15:17:18 CEST] <BtbN> So going directly via AMD seems the better option [15:17:31 CEST] <wm4> djgl: our examples are often buggy and bad [15:17:49 CEST] <wm4> generally, all API functions expect aligned data, except if documented otherwise [15:17:56 CEST] <BtbN> And the shop would most likely just forward the CPU to AMD first, and not give me anything until they confirm the issue [15:18:28 CEST] <wm4> libswscale can revert to unoptimized code if alingment is not satisfied - not sure if this is documented - it probably should, because other APIs can just crash on unaligned data [15:20:47 CEST] <djgl> As I said, on x86 it instead drops pixels. [15:54:24 CEST] <beauty> If I know nginx server's bandwidth and every channel video's bitrate, could I get the maxnum supported video stream? [17:30:41 CEST] <ZeroWalker> when you make or make install with mingw32, can you select a destination folder instead of it compiling in the same folder as the source [17:32:34 CEST] <JEEB> most things let you configure a prefix [17:32:52 CEST] <thebombzen> including ffmpeg [17:32:54 CEST] <JEEB> autoconf and a lot of shell-script based things have a --prefix parameter [17:33:01 CEST] <JEEB> yes, naturally :P [17:33:05 CEST] <thebombzen> lol [17:33:19 CEST] <JEEB> also the weird part is that he's talking about "compilation" [17:33:26 CEST] <JEEB> never tried out-of-tree compilation? [17:33:42 CEST] <ZeroWalker> well, probably worded it wrong [17:33:43 CEST] <JEEB> and you shouldn't be using the headers and libraries from the build tree anyways, make install to a prefix and then utilize them from there [17:33:52 CEST] <ZeroWalker> just meant that the .exe files end up in another folder [17:34:16 CEST] <JEEB> --prefix and then binaries will go under <prefix>/bin and libraries under <prefix>/lib etc [17:35:00 CEST] <ZeroWalker> ah [18:27:26 CEST] <ZeroWalker> do you have to do anything special to make libx264 appear in pkg-config when configuring/compiling it? [18:29:04 CEST] <JEEB> if your prefix is custom you have to override PKG_CONFIG_PATH (appends to the search path) or PKG_CONFIG_LIBDIR (clears the search path) [18:29:35 CEST] <JEEB> latter is useful if you're building on, say, system with 64bit libraries in the default path and you want to build 32bit [18:31:53 CEST] <ZeroWalker> hmm, i do use the the latter, will do some testing [18:32:55 CEST] <JEEB> remember that it should be set to <prefix>/lib/pkgconfig [18:33:01 CEST] <JEEB> not just <prefix>/lib [18:33:12 CEST] <JEEB> also do check that you actually enabled the libraries with x264 :P [18:33:21 CEST] <JEEB> (it defaults to command line encoder only) [18:46:29 CEST] <ZeroWalker> well firstly i guess it might be good to actually be able to compile the thing, noticed it failed and my stuff were from a very old compilation i did -_-- [18:47:26 CEST] <ZeroWalker> i just get complains that no working C compiler can be found. I can compile with CC=cl, but it fails on some stuff later [18:47:52 CEST] <ZeroWalker> not sure why it can't find any working c compiler. gcc --version shows: gcc.exe (Rev2, Built by MSYS2 project) 7.1.0 [18:48:41 CEST] <RiCON> you sure you installed and are using mingw gcc and not msys gcc? [18:49:41 CEST] <ZeroWalker> well i would hope so, isn't Msys the CLI for it [18:49:59 CEST] <RiCON> not necessarily [18:50:18 CEST] <ZeroWalker> i got folders for mingw32 and mingw64 which does seem to have the compilers etc [18:50:34 CEST] <RiCON> `which gcc` should return /mingw64/bin/gcc, not /usr/bin/gcc [18:50:40 CEST] <ZeroWalker> ah [18:50:55 CEST] <ZeroWalker> /mingw32/bin/gcc [18:51:23 CEST] <RiCON> check config.log then [18:52:09 CEST] <RiCON> though this conversation is way offtopic, this is neither #ffmpeg nor #x264 [18:52:56 CEST] <ZeroWalker> oh, the plan is to just compile ffmpeg with it so thought it was ok, my bad [18:56:22 CEST] <thebombzen> ZeroWalker: #ffmpeg-devel is for development of ffmpeg itself, not just compiling it or using it [18:57:06 CEST] <ZeroWalker> does programming with the ffmpeg API count? [18:57:38 CEST] <JEEB> no [18:57:39 CEST] <thebombzen> "Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg" - the title [18:57:42 CEST] <JEEB> that's #ffmpeg [18:58:26 CEST] <ZeroWalker> ah, well thing is everytime i have asked there, it's always about the CLI, so thought it wasn't for API at all [19:17:28 CEST] <durandal_1707> https://transfer.sh/CUFkZ/ffedit.png [19:53:51 CEST] <durandal_1707> perhaps i should use libmpv [20:09:41 CEST] <wm4> durandal_1707: I could make lavfi filters runtime changeable lol [20:10:28 CEST] <durandal_1707> how? [20:11:04 CEST] <wm4> I mean you could set it as option/property while video is loadd [20:11:07 CEST] <wm4> *loaded [20:28:27 CEST] <ubitux> durandal_1707: feel free to use sxplayer :p [20:28:41 CEST] <ubitux> it has exact seek support [20:28:45 CEST] <ubitux> it's monostream though [20:28:59 CEST] <ubitux> (so you pick only video typically) [20:29:11 CEST] <durandal_1707> sxplayer? [20:29:23 CEST] <ubitux> https://github.com/stupeflix/sxplayer [20:30:36 CEST] <ubitux> not sure it fits your needs [20:34:38 CEST] Action: wm4 sees messy VT code [20:56:33 CEST] <ubitux> wm4: yeah... [20:56:56 CEST] <ubitux> could get rid of it if ffmpeg did support async [20:57:09 CEST] <ubitux> which is not possible due to hwaccel model [20:57:14 CEST] <ubitux> same story over again [21:00:26 CEST] <wm4> should bring this up again in libav-devel [21:00:31 CEST] <wm4> how do you handle reordering btw.? [21:10:52 CEST] <ubitux> i use packet pts [21:15:20 CEST] <wm4> that's almost the only thing that stops us from having a vt full stream decoder [00:00:00 CEST] --- Sun Aug 13 2017

1 0

ffmpeg.log.20170812
by burek 13 Aug '17

13 Aug '17

[00:00:52 CEST] <c_14> where are you putting the option? [00:02:08 CEST] <c_14> should go before -i apparently [00:02:15 CEST] <c_14> changed from global options to demuxer-private options [00:02:28 CEST] <alexpigment> oh really? [00:02:32 CEST] <alexpigment> lemme try that [00:02:45 CEST] <c_14> since 2011 apparently [00:03:14 CEST] <alexpigment> same deal [00:03:17 CEST] <alexpigment> unrecognized option [00:05:09 CEST] <alexpigment> https://pastebin.com/B1NQPyCp [00:09:41 CEST] <c_14> That doesn't look like DV1394 [00:09:44 CEST] <c_14> What are you trying to do? [00:10:06 CEST] <alexpigment> ? [00:10:13 CEST] <alexpigment> this is atsc [00:10:20 CEST] <alexpigment> not dv [00:10:54 CEST] <c_14> yeah, that option just doesn't do what you want it to do? [00:10:59 CEST] <c_14> What's the problem you're trying to solve? [00:11:21 CEST] <alexpigment> i'm trying to make sure this video is tagged to match exactly a specification [00:11:33 CEST] <alexpigment> and the "standard" is being reported as Component by MediaInfo [00:11:37 CEST] <alexpigment> I'd like it to say NTSC [00:12:04 CEST] <alexpigment> sure, it's metadata, but there's an option for ffmpeg to set that, and that option is currently unrecognized [00:12:22 CEST] <alexpigment> on top of that, there's a deprecated option (tvstd), which explicitly tells you to use that option instead [00:12:52 CEST] <c_14> the only thing that comes close to that is -target, but I'm not sure you want that [00:13:03 CEST] <alexpigment> yeah i think target is pretty limited [00:13:17 CEST] <c_14> Everything other than that you'll have to do manually [00:13:19 CEST] <JEEB> it can't be before -i because it's an option for mpegtsenc [00:13:27 CEST] <JEEB> if you mean the standard thing [00:13:44 CEST] <c_14> Is it? [00:13:48 CEST] <JEEB> yes [00:13:55 CEST] <JEEB> mpegts_flags system_b [00:13:56 CEST] <c_14> I can only find -standard as an option for the dv thingy [00:13:57 CEST] <JEEB> it seems [00:14:07 CEST] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mpegtsenc.c#L1923 [00:14:24 CEST] <JEEB> no wait [00:14:26 CEST] <JEEB> ATSC is default [00:14:38 CEST] <JEEB> alexpigment: then you might want to check WTF mediainfo is reading from its source [00:14:56 CEST] <JEEB> otherwise it's hard to know what the flying fuck you want to match [00:15:39 CEST] <ars> hello guys [00:16:00 CEST] <alexpigment> JEEB: so I guess I'm going to have to dig through the MediaInfo source code? I'm pretty green on any sort of programming [00:16:04 CEST] <JEEB> yes [00:16:12 CEST] <JEEB> that's the problem with mediainfo [00:16:13 CEST] <JEEB> :P [00:16:27 CEST] <alexpigment> for what it's worth, i'm able to set this option easily with x264 [00:16:37 CEST] <JEEB> so what exactly is it that you want [00:16:42 CEST] <JEEB> I understood you wanted ATSC MPEG-TS? [00:16:46 CEST] <alexpigment> yeah [00:16:55 CEST] <JEEB> well that you're already getting so it's something else [00:17:00 CEST] <JEEB> esp. if you're talking about x264 [00:17:06 CEST] <JEEB> which doesn't do MPEG-TS to begin with [00:17:13 CEST] <alexpigment> but those are usually flagged with a tv standard which is the generic NTSC/PAL etc, even though those are technically innacurate [00:17:32 CEST] <JEEB> the moment you said you could set it with x264 it is not MPEG-TS level [00:17:47 CEST] <JEEB> please switch over and say what you actually want to set. "constant frame rate"? [00:17:49 CEST] <JEEB> in libx264 [00:18:09 CEST] <alexpigment> I'm not understanding what you're saying [00:18:20 CEST] <alexpigment> I'd like mediainfo to report my file as "NTSC" for the Standard [00:18:22 CEST] <ars> I have problem. error while loading shared libraries: libva.so.1: cannot open shared object file: No such file or directory. Looks like it not linked statically. But i compile like: configure --enable-libmfx --enable-nonfree --enable-gpl --disable-shared --enable-static [00:18:26 CEST] <alexpigment> there is a parameter to specify this in FFMPEG [00:18:28 CEST] <alexpigment> it is called -standard [00:18:34 CEST] <alexpigment> it is unrecognized [00:18:38 CEST] <alexpigment> according to ffmpeg [00:18:39 CEST] <JEEB> no, that is something else specific to a certain input module [00:18:56 CEST] <JEEB> 1) you just said you could set whatever you want with x264 easily [00:19:04 CEST] <alexpigment> yes [00:19:10 CEST] <JEEB> 2) "if 1), then it is not MPEG-TS" [00:19:16 CEST] <JEEB> because x264 doesn't do MPEG-TS [00:19:22 CEST] <JEEB> thus, most likely waht you need is a libx264 parameter [00:19:25 CEST] <alexpigment> i'm not using MPEG-2 in an MPEG-TS container. I'm unable to set the equivalent flag [00:19:34 CEST] <alexpigment> *now using [00:19:54 CEST] <JEEB> ok, unfortunately I don't know the flying fuck about the mpeg2 encoder [00:20:05 CEST] <JEEB> nor do I know which flag mediainfo is looking for then [00:20:09 CEST] <JEEB> since each video format is different [00:20:21 CEST] <alexpigment> fair enough. happy friday JEEB :) [00:20:31 CEST] <JEEB> in any case, look for parameters in the mpeg2 video encoder [00:20:41 CEST] <JEEB> while looking at what the flying fuck mediainfo is looking for [00:20:54 CEST] <JEEB> that way you can find out what you need and if the mpeg2 video encoder can write that [00:21:10 CEST] <alexpigment> source code is all gibberish to me. i come in here because you guys are good at knowing what that gibberish usually means [00:21:25 CEST] <alexpigment> JEEB: sounds good. thanks for your time [00:21:31 CEST] <JEEB> we can't know what Random Application X wants exactly [00:21:34 CEST] <alexpigment> go have a beer and forget this conversation happened [00:33:39 CEST] <JEEB> ok, quickly scrolled through examples of strings "frame" and "time" in libavcodec/mpegvideo_enc.c [00:33:46 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/mpegvideo_enc.c;h… [00:34:13 CEST] <JEEB> and a few other usages of time base [00:34:17 CEST] <JEEB> that's all one gets [00:34:35 CEST] <JEEB> so I recommend looking up whatever the fuck mediainfo is reading :D [00:35:38 CEST] <JEEB> if you can override the time base, I recommend trying that in case that helps for the video encoder (in the weird case where it will utilize the time base for some header field in another mpegvideo related file) [00:36:03 CEST] <JEEB> alexpigment: also do you even know if you can get this field shown with MPEG-2 Video? [00:36:14 CEST] <JEEB> or are you basing on the fact that it is showing it with AVC [00:36:24 CEST] <JEEB> and don't even knwo if it will show up with MEPG-2 Video at all [00:36:56 CEST] <thousand> Hi folks, Sorry for jumping to question. I'm seeking a one liner command for quickly adding some start and end music to my video podcast. I have music.mp3 and video.mp4. How can I do this? Thanks in advance. [00:38:35 CEST] <JEEB> well it may be fucked with a rusty spork http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/mpeg12enc.c;h=f45… [00:40:41 CEST] <JEEB> alexpigment: so if you were setting --fps XX with x264, the closest is to make sure the video encoder's time base is correct. that should write the frame rate value as per that file I linked [00:41:58 CEST] <JEEB> but yea, check mediainfo source code to make sure what you're hunting [00:42:38 CEST] <JEEB> and now, I've wasted enough time and effort into this bullshit of "I want to see this thing exactly this way in mediainfo" without having the slightest idea of what the fuck mediainfo is showing [00:59:32 CEST] <jkqxz> alexpigment: Sounds like you want to set video_format in the sequence display extension. Edit <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/mpeg12enc.c;h=f45…> to write 2 rather than 0. [00:59:55 CEST] <alexpigment> sorry, was away for a few minutes [01:00:01 CEST] <jkqxz> (<https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.262-200002-S!!PDF…> table 6-6 for possible values.) [01:00:44 CEST] <alexpigment> JEEB: I appreciate your efforts, but seriously, there's no need to get angry about it. I know it's a field that other MPEG-2 videos have and show in MediaInfo [01:01:33 CEST] <alexpigment> jkqxz: OK, is there a way to specify that in the command line parameters for FFMPEG while encoding with mpeg2video? [01:02:54 CEST] <JEEB> jkqxz: so that's different from the frame rate header the encoder is already writing? [01:03:17 CEST] <alexpigment> it's definitely decoupled from the frame rate [01:03:19 CEST] <jkqxz> Yes, it's unrelated to the framerate. [01:03:22 CEST] <JEEB> ok [01:03:23 CEST] <alexpigment> because i have the correct rate [01:03:45 CEST] <alexpigment> it's just showing "Component" in mediainfo because it's not being explicitly specified as NTSC [01:03:48 CEST] <jkqxz> It's a single field which ffmpeg hardcodes, which you can edit the line I linked above to change. [01:04:11 CEST] <JEEB> if it has various parameters I think if someone cares enough it should be an AVOption or something like that [01:04:15 CEST] <alexpigment> ok, so it has to be done in the source code as a global change? [01:04:19 CEST] <jkqxz> No, it's showing component because it's hardcoded to that. No idea who thought that was a good idea (maybe because it's zero) - five is "unspecified", which it should be. [01:04:31 CEST] <JEEB> alexpigment: anyways I just fucking hate mediainfo because it ends up with people like you coming up and having no idea of what they actually want [01:04:44 CEST] <JEEB> other than "it shows up like that in mediainfo" [01:04:55 CEST] <alexpigment> JEEB: apologies. I tried to be clear in stating that I want it to say NTSC instead of Component [01:05:15 CEST] <alexpigment> so that it matches the *other MPEG-2 videos I'm using as references* [01:05:17 CEST] <JEEB> yes, but that doesn't tell anyone on which level that field is [01:05:22 CEST] <JEEB> or where it is [01:05:37 CEST] <JEEB> jkqxz just happened to know MPEG-2 Video headers I guess [01:05:46 CEST] <JEEB> and that the field was there [01:05:53 CEST] <JEEB> which mediainfo might be parsing for that [01:06:16 CEST] <JEEB> anyways if the default is a weird value please raise a bug on trac [01:06:20 CEST] <alexpigment> I would hope they're parsing something :) there's nothing "component" about my command line [01:06:45 CEST] <alexpigment> JEEB: defaulting to anything else is not ideal either [01:06:46 CEST] <jkqxz> I only know it off-hand because it was an obvious thing to make settable with the mpeg2_metadata bsf, but that isn't merged anywhere yet. [01:07:04 CEST] <alexpigment> it needs to be a feature request, I believe [01:07:05 CEST] <JEEB> oh right, you did that one :P [01:07:22 CEST] <JEEB> that makes sense then for you to know the fields in memory [01:07:45 CEST] <JEEB> now the real question is whether that field actually does anything in actual use [01:07:50 CEST] <JEEB> most likely: not [01:07:53 CEST] <alexpigment> JEEB: i agree [01:07:59 CEST] <alexpigment> most likely not [01:08:32 CEST] <alexpigment> but when you're putting a file out there with an unknowable amount of destinations and combinations of hardware and software, it's a good idea to have your bases covered in case something *does* care [01:08:54 CEST] <alexpigment> which is my general rule with encoding videos. be as explicit as possible just in case [01:09:05 CEST] <JEEB> then fucking start learning those header values at some point [01:09:19 CEST] <alexpigment> JEEB: your attitude is seriously caustic [01:09:38 CEST] <alexpigment> i appreciate your efforts. please calm down about this [01:09:40 CEST] <JEEB> maybe, I'm just tired of people like you coming with only "mediainfo shows me X" [01:09:57 CEST] <JEEB> and that seriously burns me down and even knowing that I still go through code because I'm a fucking idiot [01:10:05 CEST] <alexpigment> JEEB: then consider me "one of those people" and set your client to block my posts [01:11:05 CEST] <JEEB> but seriously, if you are working with this shit you should have a basic understanding of this stuff better than me if you're working with MPEG-2 Video [01:11:12 CEST] <JEEB> in broadcast [01:11:31 CEST] <alexpigment> JEEB: i know video encoding. i know *nothing* about source code, programming, development, anything [01:11:38 CEST] <alexpigment> consider the fact that my skillset doesn't align with yours [01:11:51 CEST] <JEEB> where did I say coding [01:11:52 CEST] <alexpigment> consider that i'm not being lazy, but that I'm ignorant [01:11:53 CEST] <JEEB> I said goddamn fields [01:12:01 CEST] <JEEB> in your goddamn video stream [01:12:11 CEST] <alexpigment> please let me know how i can find such fields [01:12:12 CEST] <JEEB> unless you were just uanble to tell me that it was a mpeg-2 video header called X [01:12:19 CEST] <alexpigment> open my video up in a text editor? [01:12:41 CEST] <alexpigment> again, consider my ignorance here. i don't know where to look to provide the information you're talking about [01:12:42 CEST] <JEEB> if nothing else, hex editor. there are multiple stream parsers for video formats as well [01:12:48 CEST] <alexpigment> like? [01:12:58 CEST] <JEEB> elecard etc [01:12:59 CEST] <alexpigment> i'm interested in learning [01:13:13 CEST] <JEEB> also there's the patch set jkqxz is making that's on the libav-devel ml [01:13:14 CEST] <alexpigment> ok, i'll look into that on monday [01:13:17 CEST] <JEEB> which can print header values [01:13:23 CEST] <jkqxz> The standard is by far the best reference for this sort of thing. [01:13:27 CEST] <JEEB> yes [01:13:33 CEST] <JEEB> having the spec on hand is the nr1 thing [01:13:41 CEST] <JEEB> it even was linked by jkqxz [01:14:16 CEST] <alexpigment> noted [01:14:35 CEST] <alexpigment> anyway, i appreciate your help [01:15:19 CEST] <alexpigment> JEEB: seriously, i don't want to make an enemy here. I don't know if I'm actually that annoying or if you're having a bad day. But if it helps ease things over, I'll gladly paypal you a beer (as 2017 as that sounds) [01:16:45 CEST] <JEEB> unless I have a vivid memory of you each case of me herping a derp is separate. I just saw a person who didn't even look at encoder/muxer options and poked random parameters and couldn't specify what field he wanted to set where. [01:17:48 CEST] <alexpigment> JEEB: you're right. i'm googling for answers when I can't find them in the encoder/muxer options. it's my fault for assuming that there are more parameters that what's there [01:18:08 CEST] <JEEB> there was a help thing to list options for demuxers, muxers etc [01:18:21 CEST] <JEEB> I don't remember it by heart so you'll have to find it out :P [01:18:29 CEST] <alexpigment> yes, i'm familiar with it [01:18:29 CEST] <JEEB> it listed all the module-specific AVOptions [01:18:35 CEST] <alexpigment> -h encoder=mpeg2video [01:18:52 CEST] <JEEB> in this case there was no such thing, and you will want to make a ticket to make that field so you long for to be an avoption [01:19:00 CEST] <JEEB> and then you will have to hope that someone cares enough :) [01:19:19 CEST] <alexpigment> right. i'm going to log a feature request [01:19:20 CEST] <JEEB> (or you make an additional option yourself which shouldn't be too hard) [01:19:42 CEST] <jkqxz> JEEB: <http://sprunge.us/fFgX>? [01:19:44 CEST] <alexpigment> I just don't even know where to begin with that [01:20:08 CEST] <JEEB> jkqxz: that comment is fucking weird. what does components even mean there [01:20:19 CEST] <JEEB> maybe one would understand by reading the spec [01:20:31 CEST] <JEEB> but yes, unless components means something funky that looks like a better default value [01:20:32 CEST] <jkqxz> Yep, one does! [01:20:57 CEST] <alexpigment> component i think means that it comes from component video. i don't know why that's useful though... [01:21:11 CEST] <JEEB> well ye, but what's the meaning of that in the context of mpeg-2 video [01:21:19 CEST] <JEEB> if there is such a special meaning [01:21:24 CEST] <JEEB> if not, then "unknown" is better [01:21:39 CEST] <alexpigment> yeah, although one better is just being able to specify NTSC or PAL [01:21:49 CEST] <alexpigment> which are the only two meaningful options [01:21:57 CEST] <alexpigment> (to me, anyway) [01:22:11 CEST] <JEEB> alexpigment: I recommend looking into a patch that adds another AVOption into another module, which should be a small thing [01:22:18 CEST] <JEEB> and then trying to mimic that :P [01:22:56 CEST] <alexpigment> JEEB: that sits with my brain better. I guess I need to get an IDE though? [01:23:01 CEST] <JEEB> nope [01:23:03 CEST] <jkqxz> Only NTSC or PAL? You forgot SECAM! [01:23:05 CEST] <JEEB> just a sane text editor is enough [01:23:28 CEST] <alexpigment> jkqxz: yes, secam. good old secam. is that even a thing anymore??? :) [01:23:37 CEST] <JEEB> in VHS at least [01:23:46 CEST] <JEEB> and you still find TVs sold with SECAM support [01:23:51 CEST] <alexpigment> yeah, i have an NTSC/PAL/SECAM VCR actually [01:24:10 CEST] <alexpigment> i have a lot of VCRs, as weird as that sounds [01:24:15 CEST] <voip_> Hi guys i have error: error while loading shared libraries: libva.so.1: cannot open shared object file. Can i copy libva.so.1 from PC where i compiled ffmpeg ? [01:25:32 CEST] <jkqxz> voip_: Possibly, and it will likely need some of the other libva-foo libraries as well. But, libva is just a dynamic loading shim, so you won't be able to actually load any driver without more stuff as well. [01:26:23 CEST] <voip_> jkqxz, thnk you. Because i dont want compile one more time and setup Intel DSk [01:26:30 CEST] <voip_> sdk [01:26:52 CEST] <alexpigment> JEEB: your suggestion about finding something similar and copying it is actually quite helpful. i know it probably seems dumb, but to a non-developer, the idea of submitting a patch seems like something that would take some training to do. [01:26:56 CEST] <Sgeo> I have some Indeo3 videos whose dimensions are not divisible by 4. Why does ffmpeg have that restriction on Indeo3? [01:27:16 CEST] <Sgeo> And are there any non-ffmpeg based viewers I can try? [01:27:17 CEST] <alexpigment> Sgeo: that's pretty common for video encoders [01:27:37 CEST] <alexpigment> or are you talking about decoding the video? [01:27:42 CEST] <Sgeo> Decoding [01:27:52 CEST] <JEEB> Sgeo: file a bug report on the trac and post a sample if only possible [01:28:10 CEST] <JEEB> clearly someone had the idea that there was a limitation like that [01:28:20 CEST] <JEEB> but if valid files exist that are like that then that's a bug [01:28:25 CEST] <Sgeo> Um, my samples might be a copyright violation. I took them from a game. [01:28:44 CEST] <JEEB> almost any sample is under some sort of copyright :P [01:28:55 CEST] <JEEB> that's why people tend to try to cut them as much as possible [01:29:11 CEST] <JEEB> as it is specifically for sample [01:29:14 CEST] <JEEB> reasons [01:30:55 CEST] <Sgeo> If I use video codec and audio codec copy on something ffmpeg considers invalid, will it still copy the video data? [01:31:49 CEST] <Sgeo> If not, then I might not really have a valid sample unless I upload a 300MB file [01:35:09 CEST] <JEEB> what container is it in? [01:35:45 CEST] <Sgeo> .mov [01:35:47 CEST] <JEEB> if it's AVI or something and it errors out on the first frame you might be able to use virtualdub to copy things over if ffmpeg doesn't support it (it should be able to with -c copy) [01:35:56 CEST] <JEEB> ok, but it should still be able to :) [01:36:10 CEST] <JEEB> (if it can write that format altogether) [01:36:55 CEST] <Sgeo> So, the game stores its video data in one large .MOV file which apparently contains many movies. What I did was repeatedly write a skip atom at the beginning to make the .mov effectively one or another movie inside it, then use ffmpeg [01:41:01 CEST] <mfg> Hi. Does anyone here know about HLS encryption? If I wanted to have a go at sample encryption is there anyone that can help get me started. I've done fixes to the http and hls demuxers before but I don't know anything about h264. I'm trying to asses if this is within my capabilities. [01:51:34 CEST] <Sgeo> JEEB, thank you, created ticket [01:55:45 CEST] <Sgeo> Aww, virtualdub doesn't speak .mov [08:12:30 CEST] <froyo1> Is there a free online video encoding service that lets you input custom ffmpeg commands? [08:14:54 CEST] <Cracki> froyo1, it's probably faster to encode your videos on your own computer [08:15:40 CEST] <Cracki> cpu time is never free. you either pay for it with money or with other things. [08:16:25 CEST] <froyo1> @Cracki Not when it's a netbook with an Intel Atom CPU... [08:16:47 CEST] <froyo1> CloudConvert lets you do exactly this for free, except it's limited to 25 conversion mins [08:16:59 CEST] <froyo1> So I was wondering if alternatives existed [08:17:19 CEST] <froyo1> It's fine if it's paid too, if I can't find free ones [08:18:09 CEST] <Cracki> any vserver or shell provider, if you can handle ffmpeg yourself [08:19:02 CEST] <Cracki> in any case, I wouldn't know of a web service that takes custom parameters [15:50:02 CEST] <beauty> hello [15:52:24 CEST] <beauty> How get supported video stream of bitrate X in an Nginx server? Nginx server's network bandwidth is Y. [15:52:36 CEST] <BtbN> what? [15:53:45 CEST] <beauty> If I know nginx server's bandwidth and every channel video's bitrate, could I get the maxnum supported video stream? [15:55:04 CEST] <BtbN> Not sure what you're asking. Just calculate how many parallel streams fit in its available bandwidth [15:55:14 CEST] <beauty> yes [15:55:56 CEST] <beauty> I want to calculate the maxmum parallel video stream in an nginx server [15:56:10 CEST] <BtbN> so... divide the total bandwidth by the one of a single stream? [15:56:34 CEST] <beauty> how to calculate???? [15:57:06 CEST] <BtbN> uhm. With any calculator of your choice, if it's that hard to not do it manually. [15:58:01 CEST] <beauty> I can't understand you [15:58:08 CEST] <beauty> could you make it clear [15:58:47 CEST] <BtbN> It's just two numbers. Can't be that hard to do a division. [15:59:37 CEST] <beauty> but practice, it's not bandwith/bitrate [15:59:50 CEST] <BtbN> It is [16:01:01 CEST] <beauty> the distance between bandwith/bitrate and practice value is large [16:01:34 CEST] <BtbN> Make sure you use proper units [16:03:02 CEST] <beauty> what's proper unit [16:03:41 CEST] <BtbN> the same ones on both sides [16:04:42 CEST] <beauty> ????????? [16:05:02 CEST] <beauty> every ts is the same bitrate and size [16:05:27 CEST] <BtbN> I'm not able to make any sense out of what you're saying. Good luck. [16:07:24 CEST] <beauty> en [19:36:22 CEST] <thebombzen> does libvpx-vp9 not thread? [19:36:33 CEST] <thebombzen> Apparently using -threads:v 8 doesn't work [19:39:23 CEST] <thebombzen> neither does -threads 8 [19:39:28 CEST] <JEEB> the encoder if new enough should have some threading [19:39:36 CEST] <JEEB> decoder I have no idea [19:40:01 CEST] <thebombzen> I built ffmpeg this morning, the encoder is from the Arch repos (1.6.1 I think) [19:40:24 CEST] <thebombzen> now, the video is small spacially (400x300), so should that affect it? [19:40:31 CEST] <thebombzen> because it should still have frame-based threading [19:41:19 CEST] <JEEB> now that is something I don't know if libvpx has or enables by default [19:41:24 CEST] <thebombzen> it looks like this should work: ffmpeg -i input.mp4 -c:v libvpx-vp9 -b:v 0 -crf:v 31 -deadline best -c:a libopus -b:a 128k -threads 8 output.webm [19:41:25 CEST] <JEEB> for some reason a lot of vendors hate frame threading [19:41:52 CEST] <thebombzen> it's only 404x336 so if that's one slice, I can see it ignoring threading if it has no frame threading [19:42:01 CEST] <thebombzen> and the grapevine tells me that libvpx's threading is terrible [19:42:28 CEST] <thebombzen> but I feel it should still use more than one thread, especially if I turn the "extrEEEEEme" setting on (i.e. -deadline best) [19:42:47 CEST] <thebombzen> this is a 40 second 404x336 video, that took several minutes to encode [19:50:16 CEST] <Easyfab> and with -row-mt 1 did libvpx-vp9 have better threading ? [19:55:30 CEST] <Easyfab> thebombzen, for me with -row-mt 1 -threads 8 threading is enabled [19:56:23 CEST] <thebombzen> I get "unrecognized option -row-mt" [19:57:06 CEST] <Easyfab> how old is your libvpx / ffmpeg version ? [19:58:42 CEST] <thebombzen> libvpx is 1.6.1, ffmpeg was built this morning [19:58:58 CEST] <thebombzen> row-mt is in the documentation, it just complains about it [20:05:17 CEST] <thebombzen> Easyfab: so this is true if I test with git master, and also with 3.3.3 [20:05:23 CEST] <thebombzen> both using libvpx v1.6.1 [20:05:54 CEST] <thebombzen> in case you want a log, http://sprunge.us/KKcK [20:06:34 CEST] <thebombzen> if you want a nightly build log, http://sprunge.us/QcPU [20:11:56 CEST] <Easyfab> row-mt was added after 1.6.1 so you must build libvpx with recent source and not using the 1.6.1 default package. [20:15:47 CEST] <JEEB> Easyfab: let me guess, that feature is in a version that they used for a recent chromium ;) [20:16:00 CEST] <JEEB> so it is tagged as a version used in chromium but has no official release [20:18:06 CEST] <Easyfab> v1.6.1 was tagged in january and row-mt was added in february -> https://github.com/webmproject/libvpx/commit/5881601488ef4278d7ca2b06e2ad4d… [20:18:39 CEST] <Easyfab> no new stable version since january [20:18:40 CEST] <JEEB> yea, I would just guess taht the code is already in production in chromium ;) [20:18:51 CEST] <JEEB> since that's the classic way google operates [20:19:06 CEST] <JEEB> it tags things for stability for chromium, but doesn't really care about "external" releases [20:19:11 CEST] <JEEB> even though it might as well make one the other [20:19:26 CEST] <JEEB> since if you're pushing libvpx to millions with chromium you might as well call it a release :D [20:19:44 CEST] <JEEB> and then those who don't know about these tendencies in google end up using funky old versions :) [20:33:19 CEST] <Easyfab> for me (i7-2600k) without row-mt speed=0.0437x and with row-mt speed=0.168x not quite the same speed :) [21:07:46 CEST] <Ingvix> If I burn subtitles to hevc ffmpeg turns it to h264. How do I get it to keep it as hevc? [21:09:03 CEST] <JEEB> the default it picks is some default set for the container format, you generally shouldn't be trusting that selection but rather specifying what you want [21:09:21 CEST] <JEEB> as in, you should be picking one of the encoders that encodes HEVC, libx265 probably being the most popular [21:09:45 CEST] <Ingvix> I see [21:11:01 CEST] <Ingvix> so I add "-c:v libx265" to the command and that should do it? [21:11:11 CEST] <JEEB> after the input, yes [21:11:22 CEST] <JEEB> that will then use whatever are the default parameters for that encoders [21:11:22 CEST] <Ingvix> yes, thanks [21:11:24 CEST] <JEEB> *encoder [21:15:13 CEST] <Cracki> don't rely on default parameters, they're supposed to suck [21:15:24 CEST] <Cracki> at least bitrate is supposed to. [21:15:40 CEST] <JEEB> at least x264 and x265 have their defaults IIRC what the libraries' defaults are [21:16:12 CEST] <JEEB> for x264 while CRF 23 is a bit on the higher compression side, I've seen a lot of people be just happy with it (which is why it's the default in the library) [21:16:43 CEST] <JEEB> oh, and you get people asking for "best settings" while there is no magical number that's "best" [21:17:15 CEST] Action: JEEB just ends up recommending encoding ~2500 frames or so with different parameters and picking the highest CRF that still looks good [21:17:53 CEST] <JEEB> but yes, going back to that comment, if it was any of the internal encoders - totally :D 200kbps default generally doesn't end up good. at least with video. that said, libx264 and libx265 wrappers should be OK in that sense [21:19:32 CEST] <Cracki> i love 200 kbps [21:19:41 CEST] <Cracki> it tells you when someone didn't pay attention [21:20:02 CEST] <Cracki> 200k also applies to audio, didn't it... at least for one audio encoder, I once got 200k [21:20:13 CEST] <JEEB> yes, it probably is just a global avcodec default [21:20:16 CEST] <Cracki> <3 [21:24:46 CEST] <Ingvix> um, is 200kbps high or low in this case? It wasn't until recently that I got together with ffmpeg and video converting [21:25:36 CEST] <JEEB> depends on various things but don't worry - libx264 and libx265 override that default :P [21:25:48 CEST] <JEEB> so they're not affected by the global default thingamajig [21:26:09 CEST] <paperManu> bnnyyyy [21:30:20 CEST] <Ingvix> just to be sure: if I want to specify which audio track to use in the output file I need to add "-map 0:[audio stream I want]" and "-c:a copy"? [21:31:40 CEST] <Ingvix> and I only want one in the output [21:41:28 CEST] <Ingvix> and then I have to define the video stream too, it seems [21:41:38 CEST] <Ingvix> map it, I mean [22:16:54 CEST] <dorvan> hi all, I have to stream as "live view" an rtsp/rtmp input to an html visualization output, at moment I'm using a mp4 without problems for input but i can't make a good "live view" to be viewed by web, hsl and dash are excluded due big lags, ffserver seems it's no more maintened, so can be a problem adopt it. I'm here after month of tests and research on internet, now I'm searching for a... [22:16:56 CEST] <dorvan> ...definitive solution. tips to make a dinamic socket file as output are also welcome. [22:22:05 CEST] <BtbN> HLS and DASH is the best you'll get for viewing a live stream in a browser. [22:22:13 CEST] <BtbN> everything else needs Flash [22:24:59 CEST] <JEEB> in theory you could utilize an mpeg-ts parser or something from HLS.js and fuck around with HTTP if XHR lets you access the data while the connection is still going [22:25:48 CEST] <BtbN> using fragmented mp4 would be more natural [22:25:57 CEST] <BtbN> but then you essentially have DASH anyway [22:26:41 CEST] <JEEB> sure, you could just be feeding segments into this thing. and since DASH segments don't require to start with an IRAP you could even make the latency small'ish [22:26:44 CEST] <BtbN> The MediaSourceExtensions only take in mp4. So even if you managed to stream mpeg-ts to JavaScript. You'd have to make up chunks there, and end up with the same delay that causes. [22:27:39 CEST] <JEEB> but yea, this all bases upon XHR being able to feed you data while you keep the connection going [22:27:43 CEST] <JEEB> which I'm not sure is something doable [22:31:09 CEST] <BtbN> you can, but it's not overly efficient [22:31:30 CEST] <BtbN> As it will keep everything it downloaded so far in a buffer until the request finishes [22:33:34 CEST] <dorvan> JEEB: I've already used hls/ts with hls.js... but lag is high... [22:33:45 CEST] <JEEB> that's not what I was talking about [22:34:03 CEST] <JEEB> also your latency in MPEG-DASH/HLS depends on a whole lot of things in your chain to be honest [22:34:09 CEST] <JEEB> such as length of segments etc [22:34:27 CEST] <JEEB> esp. DASH lets you do funky stuff because segments don't have to start with random access samples [22:34:51 CEST] <JEEB> so you can still keep your compression efficiency, but not have as long latency [22:35:19 CEST] <JEEB> but not talking about that - some sort of streaming input is the least bad lag-wise [22:35:26 CEST] <JEEB> s/lag/latency/ [22:35:33 CEST] <JEEB> you will still have lag even if you don't have latency [22:35:57 CEST] <JEEB> (for example if you have a random access sample every ~10s then at most you have to wait for that much to get a picture but your latency can still be much lower) [22:36:57 CEST] <dorvan> ok, excluding the destination media (html), the problem it make a "remote source" input to a "local source" dinamic file as output... [22:38:11 CEST] <dorvan> where on a h264 file the needs are header format and content format (content format can be dynamic through keyframs, but header will be static) [22:38:30 CEST] <dorvan> this usually it's solved by a server.... [22:39:39 CEST] <dorvan> the best, i think, can be trasform a remote streaming in an local streaming device like /dev/video with v4l (as intermediate output) [22:39:48 CEST] <dorvan> or something like this [22:41:03 CEST] <dorvan> rstsp/rtmp -> local device/socket <- read to output [22:41:31 CEST] <dorvan> BtbN: what do you think about? [22:41:41 CEST] <dorvan> JEEB: what do you think about? [22:42:51 CEST] <BtbN> what? [22:43:07 CEST] <dorvan> the process need to be the same to make more complex operation in a chain, like motion detection, or face recognition [23:02:15 CEST] <dorvan> https://github.com/bkw/node-dronestream [23:03:47 CEST] <dorvan> BtbN: what is not clear? [23:04:27 CEST] <Cracki> I think you're unaware of the complexity of your task [23:04:49 CEST] <Cracki> there are several technologies that can be a part of the solution [23:05:26 CEST] <BtbN> in short, you're not going to be able to do low-latency streaming to a webbrowser, without utilizing either flash or WebRTC, which both is a giant mess [23:05:47 CEST] <Cracki> (I advised to use webrtc in #opencv) [23:06:19 CEST] <Cracki> I also advised to try mjpeg, since it's only happening locally anyway [23:06:26 CEST] <BtbN> streaming to a browser via WebRTC is... not exactly straight forward [23:06:41 CEST] <BtbN> I haven't figured out how to even do it at all [23:06:47 CEST] <Cracki> I've seen "content replacement" repeated jpeg "streams" [23:07:35 CEST] <dorvan> yes, mjpeg seem the less complex way, but it's not the best performance solution. [23:07:56 CEST] <Cracki> try it [23:08:16 CEST] <Cracki> unless you've tried it, you have no performance numbers [23:08:23 CEST] <dorvan> Cracki already tried. [23:08:28 CEST] <Cracki> and? [23:09:02 CEST] <kerio> mjpeg is the best [23:09:07 CEST] <kerio> you <img> [23:09:09 CEST] <kerio> and it works [23:09:11 CEST] <dorvan> Cracki: i had performance problem... so now since 3 weeks I'm on a mp4 output file take by ffmpeg [23:09:18 CEST] <BtbN> if you don't care about the massive bandwidth [23:09:21 CEST] <Cracki> be more specific please [23:09:32 CEST] <Cracki> "performance problem" [23:09:33 CEST] <BtbN> mp4 cannot be streamed [23:10:03 CEST] <Cracki> "bandwidth" on localhost is relative [23:10:11 CEST] <dorvan> kerio: 4mp frames at 30fps on many input streams... have you tips to tuning mjpeg? [23:10:19 CEST] <Cracki> downsample [23:10:36 CEST] <dorvan> BtbN: yes with some ffmpeg flags and a buffer [23:10:55 CEST] <BtbN> that's fragmented mp4 [23:11:01 CEST] <BtbN> essentially a lot of very short mp4 files [23:11:02 CEST] <Cracki> if you display multiple streams, no person viewing that is gonna profit from 30 fps. use 15 fps. [23:11:15 CEST] <dorvan> BtbN: no, monolithic. not fragmented [23:11:34 CEST] <BtbN> "monolithic" mp4 cannot be streamed due to the nature of the format [23:11:52 CEST] <kerio> do browsers support fragmented mp4 [23:11:53 CEST] <BtbN> well, it can be stream-played when the moov atom already exists [23:12:00 CEST] <BtbN> DASH is fragmented mp4 [23:12:08 CEST] <kerio> without all that bullshit machinery [23:12:14 CEST] <kerio> :^) [23:12:17 CEST] <dorvan> BtbN: can be streamed, there is a specific page on ffmpeg docs to make it.. [23:12:30 CEST] <BtbN> dorvan, you mean the page about fragmented mp4? [23:12:50 CEST] <Cracki> dorvan, you need to be a lot more specific in your statements. [23:13:09 CEST] <dorvan> BtbN: we have used 3 different solution in tests... HLS, DASH, a a trick with mp4 supported by some ffmpeg flags [23:13:19 CEST] <BtbN> fragmented mp4 can still be a single file. Basically a lot of short mp4 files stitched together [23:13:33 CEST] <dorvan> BtbN: no non the page about fragmented mp4? [23:13:42 CEST] <dorvan> BtbN: no non the page about fragmented mp4! [23:13:57 CEST] <Cracki> well which one then? [23:14:32 CEST] <dorvan> Cracki: about what? [23:14:36 CEST] <Cracki> nevermind [23:14:58 CEST] <Cracki> you've been given several alternatives. [23:15:39 CEST] <Cracki> and I still think jpeg/mjpeg can work for your application, but unless you become more forthcoming with details, you can't be helped. [23:15:40 CEST] <dorvan> Cracki: I've no real answers... only tips about already tried solutions... without considering my answers.. [23:16:25 CEST] <Cracki> if it didn't work, maybe that didn't have anything to do with the technology, but with how it's been configured [23:16:38 CEST] <dorvan> Cracki: if you read me i can provide my position about. not like BrbN position.. [23:17:30 CEST] <Cracki> ¯\_(Ä)_/¯ [23:17:34 CEST] <dorvan> Cracki: you know how to use a local device with v4l in ffmpeg like a usb cam? dev /dev/video0 for example... [23:18:10 CEST] <dorvan> Cracki: do you know what happen in /dev/video0 ? [23:18:54 CEST] <dorvan> Cracki: I need to have the same pointer for a remote stream. [23:19:17 CEST] <dorvan> input format it's not a problem... conversion it's not a problem... [23:20:17 CEST] <dorvan> output it's a problem... and it's the like Mjpeg stream with <img> like say kerio [23:20:55 CEST] <Peste_Bubonica> Hi folks. I'm trying to encode x264 to x265, using ffmpeg 3.3.3 and hevc_nvenc [23:21:10 CEST] <BtbN> *h [23:21:23 CEST] <Peste_Bubonica> this is the command line: ffmpeg -i input.mkv -vcodec hevc_nvenc -pix_fmt yuv420p10 -preset hq -2pass 1 -vb 8000k -acodec copy output.mkv [23:21:27 CEST] <BtbN> x264/4 is not a codec [23:21:36 CEST] <Peste_Bubonica> and this is the error: [hevc_nvenc @ 0xc18e20] Cannot init CUDA [23:22:01 CEST] <BtbN> Is this on Windows or Linux? [23:22:03 CEST] <kerio> your issue is that ffmpeg can't init CUDA [23:22:03 CEST] <dorvan> BtbN: probably you are a Bot! :-) [23:22:08 CEST] <Peste_Bubonica> Linux [23:22:22 CEST] <BtbN> Is your nvidia driver working properly otherwise? [23:22:29 CEST] <dorvan> Peste_Bubonica: h264 h265 ..... are the codec [23:22:49 CEST] <Peste_Bubonica> BtbN, I think so. I can play games here for example [23:22:57 CEST] <Diag> on linux? [23:22:57 CEST] <Diag> psh [23:23:02 CEST] <Peste_Bubonica> driver version is: 381.22 [23:23:07 CEST] <Cracki> games don't mean cuda/nvenc can be used [23:23:22 CEST] <BtbN> Well, them working means the driver is working [23:23:27 CEST] <JEEB> esp. since some distros even separate the packages [23:23:30 CEST] <Cracki> should... [23:23:31 CEST] <JEEB> against nvidia's wishes [23:23:32 CEST] <Cracki> what GPU is it? [23:23:38 CEST] <Peste_Bubonica> a GTX 1070 [23:23:45 CEST] <JEEB> so you might have the drivers installed, but not the CUDA stuff [23:23:53 CEST] <Cracki> ok recent enough :P [23:23:55 CEST] <BtbN> It's most likely something with your driver installation, yeah [23:24:09 CEST] <BtbN> The cuda library is not missing, that would throw a diffrent error [23:24:20 CEST] <BtbN> It just fails on the most basic thing it can do [23:24:30 CEST] <JEEB> ok [23:24:41 CEST] <Peste_Bubonica> I can check for something specific to my distro about cuda support. [23:24:46 CEST] <Cracki> see if you can find a tool to "detect cuda devices" [23:24:59 CEST] <BtbN> ffmpeg can be such a tool [23:25:03 CEST] <Cracki> ah good [23:25:05 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/release/3.3/libavcodec/nvenc.c#L442 [23:25:09 CEST] <BtbN> this is where the error comes from [23:25:37 CEST] <BtbN> cuInit is like... by far the most basic CUDA function. I can't think of a good reason for it to ever fail, other than the driver or the system being massively messed up [23:25:52 CEST] <Cracki> can I assume this code will always grab a device? there are env vars that direct which devices/classes to use... [23:26:09 CEST] <BtbN> cuInit is way before it even cares about devices. [23:26:13 CEST] <Cracki> ah [23:26:52 CEST] <Peste_Bubonica> I need to install some specific to use hevc_nvenc? [23:26:56 CEST] <dorvan> Peste_Bubonica: you need 3 components, nvidia video codec and encoder, and cuda [23:27:04 CEST] <BtbN> Usually just the nvidia-driver is enough [23:27:13 CEST] <BtbN> But who knows what your specific distro did to it [23:27:19 CEST] <BtbN> maybe they split it up and something is missing [23:27:19 CEST] <JEEB> because nvidia distributes it all in a single package [23:27:23 CEST] <Peste_Bubonica> I see. I'm using Gentoo. [23:27:26 CEST] <JEEB> BtbN: or mismatching versions [23:27:32 CEST] <BtbN> you're safe on Gentoo. [23:27:39 CEST] <BtbN> There only is one monolithing nvidia-driver [23:28:09 CEST] <BtbN> can I see lsmod | grep nvidia please [23:28:12 CEST] <dorvan> Peste_Bubonica: me also, if you need i've the pkg list you need.. [23:28:22 CEST] <Peste_Bubonica> course, one moment [23:28:53 CEST] <Peste_Bubonica> BtbN, https://pastebin.mozilla.org/9029569 [23:29:09 CEST] <BtbN> modprobe nvidia_uvm [23:29:15 CEST] <BtbN> and then try again with ffmpeg/nvenc [23:29:42 CEST] <Peste_Bubonica> BtbN, this module don't exists here [23:29:52 CEST] <Peste_Bubonica> modprobe: FATAL: Module nvidia_uvm not found in directory /lib/modules/4.9.34-gentoo [23:30:07 CEST] <dorvan> Peste_Bubonica: .... you have compiled ffmpeg with nvenc? and followed by emerge -uDN --with-bdeps=y @world ? [23:30:10 CEST] <BtbN> you're missing the uvm useflag on the nvidia-drivers then [23:30:14 CEST] <BtbN> Pretty sure CUDA needs that [23:30:23 CEST] <Peste_Bubonica> nice, let me check [23:30:47 CEST] <dorvan> Peste_Bubonica: dev-util/nvidia-cuda-sdk dev-util/nvidia-cuda-toolkit media-gfx/nvidia-cg-toolkit media-video/nvidia-video-codec sys-firmware/nvidia-firmware x11-drivers/nvidia-drivers [23:31:00 CEST] <dorvan> Peste_Bubonica: check USE with eix.... [23:31:11 CEST] <BtbN> you don't need any of those, except the nvidia-drivers [23:31:32 CEST] <Peste_Bubonica> BtbN, you are right, the i'm not using uvm useflag [23:31:33 CEST] <dorvan> Peste_Bubonica: check the requirements on rebuilds [23:31:56 CEST] <Peste_Bubonica> dorvan, thanks, I will try it right after rebuild the driver [23:31:57 CEST] <dorvan> BtbN not true with cuda, but probably it's like the question of mp4 [23:32:28 CEST] <BtbN> yes, it is true. ffmpeg bundles all the needed dependencies. It only needs the runtime libraries from the driver. [23:32:50 CEST] <dorvan> Peste_Bubonica: check the version alignement are changing something on that side.. [23:33:51 CEST] <Peste_Bubonica> not it works BtbN [23:33:59 CEST] <Peste_Bubonica> its the uvm module [23:34:01 CEST] <BtbN> *now? [23:34:09 CEST] <dorvan> Peste_Bubonica: media-video/nvidia-video-codec it's aligne with latest CUDA toolkit, check it with nvenc use flags, if you have problem, check it through opencv. [23:34:27 CEST] <Peste_Bubonica> i've recompiled the driver and loaded nvidia_uvm and its running [23:34:34 CEST] <Peste_Bubonica> 154 fps [23:34:42 CEST] <BtbN> yeah, CUDA needs the unified memory thing [23:34:48 CEST] <ZeroWalker> been trying to compile ffmpeg with libx264 for ages now, why is it so hard:( [23:35:16 CEST] <Peste_Bubonica> dorvan, this codec is from 6.0.1 version on gentoo [23:35:32 CEST] <Peste_Bubonica> i've read that ffmpeg bundles the 8x version in 3.3 version, its right? [23:35:55 CEST] <BtbN> yes, ffmpeg has no external build time dependencies for cuvid and nvenc [23:36:17 CEST] <BtbN> It only loads cuda/nvenc at runtime. And those libs come from the driver [23:36:21 CEST] <BtbN> no need for all those SDKs at all [23:36:47 CEST] <Peste_Bubonica> very good [23:36:50 CEST] <BtbN> Except if you need/want scale_npp or scale_cuda [23:36:57 CEST] <BtbN> those actually require the CUDA SDK [23:37:22 CEST] <Peste_Bubonica> I will check now, if mpv can use hardware decoding for x265 [23:37:26 CEST] <Peste_Bubonica> after loading this module [23:37:37 CEST] <BtbN> probably not on its own [23:37:57 CEST] <Peste_Bubonica> BtbN, I think that they use ffmpeg to decode [23:38:14 CEST] <BtbN> Yeah, but hw accelerate decoding is not automatic [23:38:35 CEST] <dorvan> Peste_Bubonica: what's you use case for this? [23:39:09 CEST] <Peste_Bubonica> dorvan, right now, only encode my files fast [23:39:19 CEST] <dorvan> ah ok... [23:39:20 CEST] <Peste_Bubonica> with my CPU, it was producing 25fps [23:39:37 CEST] <Peste_Bubonica> x264 to x265 [23:39:52 CEST] <BtbN> it's still h264/5 [23:39:57 CEST] <Peste_Bubonica> its not a professional usage. Only noob things :) [23:39:57 CEST] <BtbN> x264 and x265 are applications [23:39:59 CEST] <dorvan> ffmpeg with nvenc call as dependency media-video/nvidia_video_sdk-6.0.1::gentoo so it's not "including alll it self" [23:40:12 CEST] <dorvan> i've compiled it now... [23:40:14 CEST] <BtbN> That's a wrong dependency then. [23:40:18 CEST] <JEEB> ^this [23:40:23 CEST] <dorvan> BtbN [23:40:23 CEST] <kerio> hardware encoding has worse results tho [23:40:26 CEST] <dorvan> ahahah [23:40:30 CEST] <JEEB> it requires it if you want to use it [23:40:33 CEST] <JEEB> not a build-time dep [23:41:28 CEST] <BtbN> it would also be way too old to build a current ffmpeg [23:41:50 CEST] <dorvan> ffmpeg +nvenc, needs media-video/nvidia_video_sdk-6.0.1::gentoo, without -nvenc, media-video/nvidia_video_sdk-6.0.1::gentoo it's not called in... [23:42:00 CEST] <BtbN> That dependency is plain wrong. [23:42:09 CEST] <BtbN> Or you're looking at a really old ffmpeg version. [23:42:19 CEST] <dorvan> 3.3.3 [23:42:25 CEST] <BtbN> wrong dependency then [23:42:31 CEST] <BtbN> ffmpeg 3.3 has the video sdk bundled. [23:42:31 CEST] <Peste_Bubonica> dorvan, are you sure? I've installed 3.3.3 version here, without install nvidia video sdk [23:42:54 CEST] <dorvan> Peste_Bubonica: done it now, let's try... [23:42:57 CEST] <BtbN> well, "video sdk". It's a single header file. [23:43:55 CEST] <dorvan> BtbN: yes probably but it need it... not "no, it's wrong" .... [23:44:03 CEST] <BtbN> the ebuilds needs it [23:44:06 CEST] <BtbN> ffmpeg does not need it [23:44:13 CEST] <dorvan> :-) [23:44:17 CEST] <BtbN> It can plain be removed from the ebuild, it's wrong. [23:44:45 CEST] <dorvan> BtbN say to ebuild maintainer, but, pls, check it before... [23:45:03 CEST] <BtbN> You realize I'm the author and maintainer of all the nvenc/cuda stuff in ffmpeg? [23:45:13 CEST] <BtbN> I'm very well aware of what I'm saying. [23:45:27 CEST] <BtbN> well, most of it by now. [23:46:44 CEST] <dorvan> BtbN not I don't now... but I know your approach as irc user... and this suggest me to verify everything you wrote.. like you don't. [23:47:20 CEST] <Cracki> thanks for all that nvenc/cuda stuff :D [23:47:37 CEST] <dorvan> BtbN so if you are the maintainer, and as I reported to you, say to ebuild maintainer [23:47:39 CEST] <Peste_Bubonica> Before come here to ask you guys, i've installed manually the video sdk, thinking that their lack could be the cause, so I've checked that this old version, does not support hvec (6.0.1). I will need de 8x. Then I found this page: https://developer.nvidia.com/ffmpeg [23:47:49 CEST] <Peste_Bubonica> that says that ffmpeg 3.3 bundles it [23:47:59 CEST] <BtbN> dorvan, I'm not responsible for the ebuilds in Gentoo. Not a Gentoo dev. [23:48:00 CEST] <Cracki> btw, tips for making decode really fast on a gtx 560? I'm not getting beyong 160 fps (24 Mbps H.264 video from a camera) [23:48:37 CEST] <Peste_Bubonica> so I removed this codec package. Its not a dependency for ffmpeg, even with the nvenc useflag [23:48:56 CEST] <dorvan> BtbN: ok, you can simply reduce you "no" here, can be good enough :-) [23:49:11 CEST] <BtbN> 160 fps might be the best that card can do [23:49:18 CEST] <BtbN> Those older cards weren't overly fast. [23:49:35 CEST] <BtbN> But not sure, never used anything older than a 760 with nvenc/cuvid [23:50:07 CEST] <shayr> hello all, I have a small question (at least I hope it's small) [23:50:41 CEST] <Peste_Bubonica> nice. MPV is working with cuda for decoding now [23:50:42 CEST] <Peste_Bubonica> Using hardware decoding (cuda). [23:50:42 CEST] <Peste_Bubonica> VO: [opengl] 1920x816 cuda[p010] [23:50:46 CEST] <Peste_Bubonica> goood :) [23:50:46 CEST] <dorvan> BtbN: so nvenc in ffmpeg 3.3.3 does not have deps also on cuda or X ? [23:50:52 CEST] <shayr> if i want to lower the bitrate of a file to get a smaller size, what can I do to guarantee as best quality as possible? the original file is 15Mb and I really need it smaller [23:51:14 CEST] <BtbN> It has no deps on the CUDA sdk. It does depend on the cuda runtime libraries, but those come with the nvidia-driver. [23:51:43 CEST] <Peste_Bubonica> it takes 20 minutes to "recode" a 4.7GB h264 file [23:54:18 CEST] <dorvan> BtbN: dev-util/nvidia-cuda-sdk dev-util/nvidia-cuda-toolkit x11-drivers/nvidia-drivers ....seems toolkit 8.0.61, it's not included in nvidia-drivers, only libs? [23:54:50 CEST] <dorvan> Peste_Bubonica: what about I/O, hdd speed? [23:54:51 CEST] <BtbN> libcuda.so.1 and libnvidia-encode.so.1 are the only things ffmpeg needs for nvenc [23:55:21 CEST] <BtbN> Everything else it needs to compile is bundled, so no need for external dependencies at build time. [23:55:43 CEST] <Peste_Bubonica> dorvan, i've reading the file from a magetic disk, Sata 3, with 180MB/s of read speedy, and writing to an SSD that can handle about 450MB/s at max [23:57:02 CEST] <dorvan> Peste_Bubonica: how many RAM? your bottleneck it's the source.. [23:57:25 CEST] <BtbN> you can use nvidia-smi to see the video engine load [23:57:31 CEST] <BtbN> if it's at 100%, you have your bottleneck right there [23:57:52 CEST] <dorvan> BtbN: true, but on a 1070.... [23:58:02 CEST] <BtbN> he's encoding h265 [23:58:12 CEST] <BtbN> that's not that crazy fast after all [23:58:57 CEST] <Peste_Bubonica> dorvan, 32GB DDR3 1866 [23:59:34 CEST] <dorvan> BtbN: h265 does not more cpu friendly respect h265? [23:59:57 CEST] <BtbN> h265/hevc uses _a lot_ more resources to encode than h264 [00:00:00 CEST] --- Sun Aug 13 2017

1 0

ffmpeg-devel.log.20170811
by burek 12 Aug '17

12 Aug '17

[00:05:44 CEST] <iive> why on the topic of ryzen - http://i.imgur.com/KPE7E0s.jpg [00:06:37 CEST] <iive> while [00:06:52 CEST] <Compn> lol that graph [00:07:00 CEST] <Compn> such a big difference for 1 fps more LOLOLOL [00:07:07 CEST] <iive> :} [00:07:14 CEST] <jamrial> is that a parody? [00:07:18 CEST] <Compn> who made that, hilarious [00:07:18 CEST] <iive> no [00:07:26 CEST] <Compn> fractional fps hahahaha [00:07:31 CEST] <TD-Linux> I'm really interested to see some windows vs linux benchmarks of threadripper. the one I was able to find makes threadripper look a little better https://www.computerbase.de/2017-08/amd-ryzen-threadripper-test-1950x-1920x… [00:07:33 CEST] <jamrial> someone published that as part of a review? [00:07:49 CEST] <TD-Linux> I suspect it's going to be heavily reliant on the NUMA scheudler [00:07:55 CEST] <iive> it's from Techradar article, and they have changed it already. [00:08:45 CEST] <nevcairiel> thats what happens if you let your tools generate the images for you :p [00:26:37 CEST] <rcombs> iive: Compn: gdi truncated bar graphs ought to be illegal [00:27:05 CEST] <iive> yeh [00:27:33 CEST] <rcombs> at the very least ones without an indication of the truncation [00:27:48 CEST] <rcombs> you know the thing I'm talking about, the wavy-line mark on the graph axis near the bottom [00:27:53 CEST] <nevcairiel> that one has the range clearly mentioned! [00:28:16 CEST] <rcombs> in text, though, not graphically [00:28:59 CEST] <iive> some time ago there was an article, that showed all kinds of graph tricks. not starting from zero, or using 2 different scales in the same image... [00:29:21 CEST] <iive> all things to mislead the eye, before the brain can get the raw data. [04:30:30 CEST] <cone-065> ffmpeg 03Davinder Singh 07master:1939b9030642: avcodec/mjpegenc: disable unused code with AMV [04:30:30 CEST] <cone-065> ffmpeg 03Davinder Singh 07master:4116b2b136f5: avcodec/mjpegenc: cosmetic changes [11:01:05 CEST] <JEEB> interesting [11:01:14 CEST] <JEEB> so AVFrame doesn't have AVMEDIA_TYPE set to it? [11:01:20 CEST] <JEEB> you have to find it out from the context? [11:05:26 CEST] <nevcairiel> usually AVFrames don't really mix in the same API so you should really always know [11:06:47 CEST] <nevcairiel> avutil checks width/height for video frames, a nd nb_samples for audio frames [11:06:56 CEST] <nevcairiel> if you really want some rule to check =p [11:09:58 CEST] <JEEB> :D [11:10:06 CEST] <JEEB> thankfully I have the AVCodecContext around [11:10:10 CEST] <JEEB> or well, nearby [11:11:57 CEST] <wm4> av_frame functions "infer" the media type by checking certain fields [11:12:21 CEST] <wm4> see av_frame_get_buffer() [11:12:56 CEST] <wm4> but yeah, that's slightly annoying... media type and the time base would probably be the only fields that are missing for truly independent AVFrames [11:13:11 CEST] <JEEB> right, it misses that one as well :) [11:19:54 CEST] <BtbN> well, I'm not getting a replacement CPU until AMD confirms the defect on mine. Have to somehow wait 4-6 weeks without a CPU in my PC [11:20:18 CEST] <nevcairiel> time for a vacation [11:20:45 CEST] <wm4> should have bought Intel [11:23:51 CEST] <BtbN> I'm just gonna buy a replacement R5 [11:24:01 CEST] <BtbN> R3 is on backorder, so can't do that -_- [11:29:20 CEST] <BtbN> Ordered an R5 1500X. Guess I have better chances to re-sell those anyway [13:06:26 CEST] <kurosu_> Are people in here actually experiencing the ryzen crashes? [13:07:04 CEST] <kurosu_> Not the phoronix one(s) (conftest for PHP build), but on actual work [13:07:16 CEST] <BtbN> kurosu_, yes. [13:07:21 CEST] <BtbN> My 1800X is affected [13:07:44 CEST] <BtbN> Just building gcc is pretty much guaranteed to crash [13:07:57 CEST] <kurosu_> what does it crash on then? ffmpeg compilation/running? [13:08:00 CEST] <BtbN> gcc [13:09:31 CEST] <BtbN> sometimes bash, it's not deterministic at all [13:09:38 CEST] <BtbN> But mostly gcc just segfaults [13:09:39 CEST] <kurosu_> ok [13:10:21 CEST] <kurosu_> that sounds far worse then, but then the platform seems rushed (cf memory issues) [13:11:22 CEST] <wm4> and the underlying cause is unknown? does amd at least claim that it's fixed on newer revs? [13:11:34 CEST] <JEEB> yes [13:11:48 CEST] <JEEB> it claims TR/Epyc and possibly even newer lot Ryzens are unaffected [13:12:03 CEST] <BtbN> Pretty much only the people who bought Ryzen on day one are affected [13:12:24 CEST] <BtbN> chips with a UA date after week 25 of 2017 have not been found to be affected [13:12:43 CEST] <BtbN> It's not even a new stepping. Just the same one, manufactured later [13:13:19 CEST] <kurosu_> the situation is quite muddy [13:13:46 CEST] <kurosu_> BtbN case on the other hand is far more concerning, at it's nowhere near artificial [13:14:01 CEST] <kurosu_> not like I was planning to upgrade anyway [13:14:13 CEST] <BtbN> To me it seems like AMD knows they fucked up, as they agree to RMA with anyone who asks. But do not publicly announce it, which would cause thousands of CPUs to come back at them [13:20:06 CEST] <kurosu_> the issue is that the bug is likely companded with generic instability issues due to the platform (motherboard+voltage+memory) [13:20:26 CEST] <BtbN> The system is not unstable at all [13:20:38 CEST] <BtbN> I can run Prime95 and other stresstests for hours on end without a single failure [13:20:57 CEST] <BtbN> And I can also compile huge things like webkit or libreoffice without a single failure [13:21:05 CEST] <BtbN> it's just a selected few packages that fail reliably [13:21:15 CEST] <BtbN> most prominently gcc and mesa [13:21:33 CEST] <kurosu_> yeah, but those are artificial: even if it indicates possible realword issues, if you're not affected... you have issues with compilation, that's no good at all [13:21:48 CEST] <kurosu_> those = prime&co [13:21:59 CEST] <BtbN> I can imagine certain games to be affected as well [13:22:18 CEST] <BtbN> the Benchmark of Ashes of Singularity crashes as well. So the game itself likely does as well when enough is going on [13:23:02 CEST] <kurosu_> btw, why 1800X? no wish to fiddle with o/c to get the same performance level, or attempt at higher quality cpu sample ? [13:24:02 CEST] <kurosu_> (i5820k @ conservative 4.1GHz here) [13:24:04 CEST] <BtbN> best binning, and no point in OCing that for 200~300 extra MHz [13:24:22 CEST] <BtbN> It runs at 3.7GHz pretty much all the time [13:24:30 CEST] <BtbN> and Ryzen caps out at around 4GHz [13:24:58 CEST] <kurosu_> yeah, but I mean the 1700 is the same physical cpu, except for the clock [13:25:08 CEST] <BtbN> But a lower quality die [13:25:16 CEST] <kurosu_> so 1700 oc ~ 1800X (oc or not) [13:25:32 CEST] <BtbN> And I'd have to OC it, don't feel like fiddling with that just to void my waranty on things [13:26:11 CEST] <kurosu_> yeah, my point (oc'ing can be a hassle), but then warranty issues seems unlikely if you are conservative [13:27:47 CEST] <kurosu_> anyway, were I at a point I wanted to renew my cpu, I'd still go with AMD (even as a ricer that cares about that avx2 performance) [13:28:48 CEST] <BtbN> avx2 on Ryzen is not that much slower than on Intel [13:28:57 CEST] <BtbN> as it doesn't have to underclock itself to run it [13:29:23 CEST] <kurosu_> yeah, if you are not oc'ing/not overriding power usage limitations [13:30:23 CEST] <kurosu_> I'm just thinking of the architectural limitations, eg avx2 has half the ressources compared to intel newest chips (aka 2x128, like sse in the old k7 days) [13:30:43 CEST] <nevcairiel> if you don't OC in the first place, then desktop intels dont really need to downclock for avx2 [13:30:58 CEST] <nevcairiel> there is plenty headroom to use [13:31:15 CEST] <nevcairiel> servers typically do because they adhere to rather strict standards [13:31:29 CEST] <kurosu_> they still do? like voltage and clocks are forced to be reduced ? [13:31:52 CEST] <kurosu_> (whatever the clock. I mean enforced offsets, unless edited) [13:32:18 CEST] <nevcairiel> in desktop space it mostly depends what your mainboard comes with as a default [13:33:18 CEST] <nevcairiel> but its no problem to just disable that, makes temps go slightly up, but desktop platforms have plenty headroom for that [13:35:42 CEST] <kurosu_> anyway, that's an interesting point with avx512 arriving but also increasing the power usage - I'm not completely sure architecture is nowadays the limit, rather than power usage (~ OC frequency reachable within a stability margin) [13:36:27 CEST] <nevcairiel> avx512 is a lot more demanding, cant really do that without downclocking [13:36:56 CEST] <nevcairiel> but doubling the throughput again also gives a lot of FLOPS [13:37:03 CEST] <kurosu_> ryzen seems really spec'ed like haswell, and so the architectural benefits (10-20% more instruction per cycle for 7/8th gen over ryzen?) seem almost completely offset by "more cores" [13:37:26 CEST] <kurosu_> yeah, my point is the combination is not such a huge improvement [13:37:52 CEST] <nevcairiel> if the algorithm scales well, then 10-15% less clock still yields a huge improvement [13:37:57 CEST] <kurosu_> (offset within comparable power usage) [13:38:31 CEST] <nevcairiel> and recent cpus can change their clock quite rapidly [13:40:48 CEST] <kurosu_> btw, gb seems to have completely fallen off the radar - I know intel@France got a pretty rough downsizing but that seemed more "intense" than that [13:43:10 CEST] <atomnuker> kurosu_: intel cpus have 2 256 bit units capable of addition and multiplication, amd has 4 128bit of them (though IIRC 2 of them handled multiplication and 2 did addition) [13:43:13 CEST] <atomnuker> at least for FPU [13:43:28 CEST] <atomnuker> *floats [13:44:06 CEST] <kurosu_> yeah, FMA with avx2 has twice the throughput on intel compared to amd [13:44:11 CEST] <atomnuker> so its not that different but you still need to avoid doing the standard thing when writing code to not stack 2 256bit identical ops [13:44:30 CEST] <kurosu_> avx512 seems segmented though in intel hedt (10+ vs below) [13:55:05 CEST] <wm4> kurosu_: gb? [14:18:21 CEST] <kurosu_> Gwenole [14:19:24 CEST] <kurosu_> we had a discussion, I and BBB, around some of those avx2 insn "shortcomings", but he's more a gpu guy [14:19:32 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:86cbffdc4db2: avcodec/tests/dct: Add peak mean error check [14:19:33 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:84786e928f9e: avcodec/tests/dct: Add Mean square error test [14:19:34 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:511e10f673a6: avformat/avidec: Move packet skip after prefix and related checks [14:19:35 CEST] <cone-862> ffmpeg 03Michael Niedermayer 07master:7735ed29741d: avcodec/mpeg4videodec: Clear mcsel before decoding an image [14:20:07 CEST] <kurosu_> *a discussion with him [14:20:07 CEST] <wm4> kurosu_: AFAIK he stopped working at Intel a long time ago [14:21:10 CEST] <kurosu_> ok, basically what I was expecting, but with a lot less silence [14:21:51 CEST] <kurosu_> (privately or not) [15:19:38 CEST] <kierank> kurosu_: wb [15:20:42 CEST] <kurosu_> not really back (if that's the meaning), just on holidays at home :) [15:20:57 CEST] <kierank> ok [15:39:03 CEST] <ZeroWalker> hmm, when interpolating YUV2 (422), you are supposed to interpolate the first and second UV with the second Y right? so, YUVY YUVY , would be (Y+UV), (Y + (UV + UV /2)). Okay horrible math, not sure why i tried showing it like that -_- [15:56:37 CEST] <iive> ZeroWalker: you mean (Y1, (U0+U1)/2, (V0+V1)/2) ? [15:57:27 CEST] <ZeroWalker> yeah, is that how the interpolation is supposed to be, and if so, what happens on the last pixel of the line? [15:59:53 CEST] <iive> just use the same value [16:01:43 CEST] <ZeroWalker> so the last pixel does no interpolation basically? [16:03:42 CEST] <iive> what choice do you have :D [16:04:11 CEST] <J_Darnley> extrapolation! [16:04:33 CEST] <ZeroWalker> yeah i duno xD. But i haven't there been said something like "center interpolation" or maybe it was Chroma offset/position etc? so didn't know if that had something to do with it [16:04:49 CEST] <ZeroWalker> haha yeah, ultrapolation is the next step [16:34:24 CEST] <JEEB> so what was the current plan with the getters and setters for a lot of the values in AVFrames? [16:34:46 CEST] <JEEB> like av_frame_get_color_range() [16:35:45 CEST] <nevcairiel> basically dont use them [16:36:14 CEST] <JEEB> yea, that was what I had gathered before [16:36:34 CEST] <JEEB> I just wanted to double-check as I happened to look at the AVFrame documentation :) [16:37:14 CEST] <wm4> we changed it so that you don't need to use them anymore [20:35:54 CEST] <J_Darnley> LOL. The people flipping ThreadRippers have appeared. [20:36:55 CEST] <BtbN> hm? [20:37:20 CEST] <JEEB> J_Darnley: it also got some boogs_ [20:37:20 CEST] <JEEB> ? [20:37:24 CEST] <J_Darnley> I'm seeing "second hand" ones being put up for sale. [20:37:36 CEST] <JEEB> oh, in that sense [20:37:38 CEST] <JEEB> gotcha [00:00:00 CEST] --- Sat Aug 12 2017

1 0

ffmpeg.log.20170811
by burek 12 Aug '17

12 Aug '17

[04:09:49 CEST] <djgl> Hi, I noticed that the yuv2rgb routines on x86 need (width+7)/8 <= stride/8. Otherwise they will drop pixels on the right. Is this documented somewhere? [09:30:02 CEST] <Fyr> guys, can FFMPEG utilize NVIDIA Tesla? [09:43:37 CEST] <squ> some encoders can use cuda [09:44:26 CEST] <Fyr> squ, so h264_nvenc? [09:44:47 CEST] <squ> yes [09:46:10 CEST] <furq> nvenc doesn't use cuda [09:46:18 CEST] <furq> some filters can use opencl [09:46:31 CEST] <furq> and nvdec will use cuda if your card doesn't have the asic for it [09:47:47 CEST] <Fyr> furq, is there a list of the filters that support openCL? [09:47:55 CEST] <Fyr> I can't google them out. [09:48:11 CEST] <Fyr> >>OpenCL is currently only used for filtering (deshake and unsharp filters) [09:48:21 CEST] <Fyr> hwaccelintro says. [09:48:36 CEST] <Fyr> I'm sure there is more. [10:53:42 CEST] <furq> those are the only ones with opencl parameters [10:54:10 CEST] <furq> there are definitely more filters which could potentially use it if you want to contribute patches [10:54:31 CEST] <furq> i know there are some good opencl denoisers out there [14:47:47 CEST] <under9000> hi guys, I have a problem here. normally I don't resort to asking people but 30 minutes of googling, docs searching and stackexchange browsing resulted in nothing. the question is: is there an ffmpeg command line argument that tells it to REMOVE output file if it failed to convert from one container to another? [14:48:46 CEST] <furq> || rm out.mkv [14:51:39 CEST] <under9000> would it work on windows? [14:51:56 CEST] <DHE> in a batch file or powershell, you could make it work [14:56:49 CEST] <under9000> ffmpeg is being launched from youtube-dl which tells it the output filename, and I don't know of a way to tell the output filename to rm command [14:57:29 CEST] <under9000> since I can only pass additional arguments to youtube-dl which passes them on to ffmpeg [14:58:05 CEST] <under9000> am I correct to assume that ffmpeg DOESN'T have a specific command switch that tells it to remove output file on error? [15:13:49 CEST] <DHE> I can't find one in ffmpeg-all.html [15:19:02 CEST] <under9000> ok thank you [15:23:38 CEST] <dynek> hello! [15:24:45 CEST] <dynek> I'm running 3.3.3-1 and trying to use va-api with h.264 video as source [15:25:26 CEST] <dynek> I end up with a video split in two full or pinkness, let me upload a screenshot [15:26:47 CEST] <dynek> ffmpeg output: https://pastebin.com/9LmR2EHW [15:27:44 CEST] <BtbN> vaapi is pretty much untested with anything but intel [15:29:26 CEST] <dynek> screenshot: https://cloud.bs-network.net/index.php/s/zcDb3R9CC1r4xAd [15:29:50 CEST] <dynek> wanted to try vdpau but I need x11 to be running and wasnt successful using LXC [15:39:24 CEST] <jkqxz> dynek: That's made by the encoder on AMD? Read the AMD section of <https://trac.ffmpeg.org/wiki/Hardware/VAAPI>, particularly the last paragraph. [15:39:55 CEST] <dynek> jkqxz: it is - thank you I'll have a look [15:41:45 CEST] <dynek> jkqxz: I owe you a beer :-) [15:59:31 CEST] <dynek> is it possible to use va-api on the decoding side only (to avoid using cpu cycles) and only extract jpegs every seconds? [15:59:45 CEST] <dynek> trying to do so but it's as consuming with or without hwaccel flags [16:09:50 CEST] <jkqxz> Should be. What is your command line at the moment? [16:21:57 CEST] <truexfan81> so why does the ffmpeg configure script take so long? [16:22:10 CEST] <c_14> because it tests a bunch of things [16:23:52 CEST] <truexfan81> i wonder if there is an argument i can give it, to make it show what its checking, cause with it giving no output it makes it look like its frozen [16:24:07 CEST] <c_14> tail -f ffbuild/config.log [16:25:32 CEST] <truexfan81> my cpu is pegged at the moment, cause make is running with -j6 [16:39:51 CEST] <Guest80657> Hi there, does anybody have an example of transmuxing X to fragmented MP4? (it'd be better if it was ffmpeg/lib example but I'll be happy with ffmpeg command line as well). [16:40:30 CEST] <Guest80657> I found a remuxing example (using the lib) https://ffmpeg.org/doxygen/trunk/doc_2examples_2remuxing_8c-example.html but then I realize I also need to understand how to mux to fragmented mp4 not only mp4. [16:42:55 CEST] <dreampeppers99> I found some samples in the Internet telling to use `-movflags empty_moov+default_base_moof+omit_tfhd_offset` in order to obtain such fmp4 [16:44:16 CEST] <dreampeppers99> I think I found the info I need to make it through ffmpeg command line https://ffmpeg.org/ffmpeg-formats.html#mov_002c-mp4_002c-ismv [16:44:51 CEST] <JEEB> yup [16:45:05 CEST] <dreampeppers99> anyway, if anybody still has a link to an example of remuxing to fragmented mp4 using the ffmpeg lib it'd be great! [17:24:52 CEST] <Fenrirthviti> Hmm, does VBR for NVENC actually use CQP at all? [17:40:04 CEST] <leemox> Which is the best deinterlace filter right now? In the ffmpeg documentation I see that it is 5 different - bwdif, kerndeint, nnedi, w3fdif and yadif. Which one I will get the best results? [17:40:15 CEST] <leemox> https://ffmpeg.org/ffmpeg-filters.html [17:42:37 CEST] <furq> you forgot mcdeint [17:43:03 CEST] <furq> nnedi is probably the best but it's also too slow to be usable in ffmpeg [17:43:19 CEST] <furq> maybe mcdeint is good but when i tried it it was even slower than nnedi and looked terrible [17:43:28 CEST] <furq> so the answer is probably bwdif=1 [17:46:02 CEST] <leemox> Thank you very much. What about yadif? In various forums it was quite often recommended. [17:47:03 CEST] <furq> bwdif is supposedly better than yadif [17:47:06 CEST] <furq> it's worth trying both though [17:47:14 CEST] <furq> they looked basically the same last time i tested them [17:47:42 CEST] <furq> just make sure you use them both in mode 1 [17:49:38 CEST] <leemox> Why is it so important? The default settings are different (mode 0 in bwdif). I thought to trust them :-) [17:50:41 CEST] <furq> mode 1 is double framerate [17:50:44 CEST] <furq> it looks much better [17:57:31 CEST] <pgorley> hi, how do i get the number of samples in an AVStream? [17:57:52 CEST] <leemox> Have you tested w3fdif? [17:58:50 CEST] <JEEB> w3fdif is one of the two that bwdif uses (together with yadif) [17:58:52 CEST] <JEEB> IIRC [18:01:41 CEST] <leemox> Yes, indeed. Before asking previous questions, I wondered if the combination of several different methods works better than one. But as the @furq wrote, bwdif is reportedly very good. [18:01:46 CEST] <leemox> So propably yes. [18:04:07 CEST] <furq> does anyone know how to actually use mcdeint properly [18:04:14 CEST] <furq> the results were so bad when i tried it that i suspect i did it wrong [18:04:42 CEST] <iive> you need yadif included before mcdeint [18:04:46 CEST] <furq> yeah i did that [18:05:00 CEST] <furq> it ran at like 2fps on pal dvd and looked absolutely awful [18:05:09 CEST] <furq> and also spat out a ton of warnings [18:05:22 CEST] <iive> hum... haven't tried it recently. [18:06:06 CEST] <furq> i think i was just doing yadif=1,mcdeint=slow,tff [18:06:34 CEST] <furq> it's gone from my bash history now [18:28:09 CEST] <crot> Anyone have any experience trans-coding content from an hdhomerun [18:30:14 CEST] <DHE> I do. the device I have is an OTA to ethernet converter [18:33:15 CEST] <crot> Did you have any problems getting an acceptable quality overall the the streams look good but have intermittent pixelation [18:34:40 CEST] <DHE> have you watched the raw streams? antenna quality and location matters quite a bit. use the tools to measure the signal quality [18:35:14 CEST] <DHE> the other thing to watch for is that CPU isn't maxed out. this is a realtime stream. if your quality settings are too high you may be dropping packets [18:35:19 CEST] <crot> Yeah raw is good. signal levels all look great. [18:36:28 CEST] <crot> udp://235.71.0.4:1234?overrun_nonfatal=1 -vcodec libx264 -tune zerolatency -preset veryfast -profile:v high -x264opts nal-hrd=cbr:force-cfr=1 -b:v 2500k -minrate 1500k -maxrate 3500k -bufsize 3500k -a53cc 1 -acodec ac3 -ab 448000 -af 'volume=5' -vbsf h264_mp4toannexb -f mpegts 'udp://239.91.0.4:1234? [18:37:49 CEST] <DHE> I disapprove of zerolatency mode here. I know it adds another ~1-2 seconds of playback delay but the effect is has on quality is very substantial. [18:38:27 CEST] <DHE> also there's a chance the audio you're receiving is already AC3. do you need the volume boost here? [18:39:05 CEST] <crot> yeah for what ever reason the audio is coming across lower than other channels on average. [18:39:36 CEST] <crot> Stream #0:0[0x31]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, bottom first), 1280x720 [SAR 1:1 DAR 16:9], Closed Captions, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc Stream #0:1[0x34](eng): Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 448 kb/s [18:40:40 CEST] <crot> that is the ffprobe of the source stream. Would you recommend deinterlacing? [18:43:40 CEST] <Plebber> When speciifying bitrates, does 512k means the same thing as 512K? [18:44:02 CEST] <Plebber> as in is k kilobits/s and K kilobytes/s? [18:44:13 CEST] <Plebber> I can't find documentation for these abbreviations [18:45:39 CEST] <c_14> I think K is bytes and k is bits [18:46:33 CEST] <Blubberbub_> isnt the difference that one is 1000 and the other is 1024? [18:47:12 CEST] <Blubberbub_> (thats what wikipedia says - no clue how that is implemented in ffmpeg) [18:48:46 CEST] <Plebber> But what about ffmpeg? [18:49:46 CEST] <Plebber> If I said make a video with a 1 megabyte per second bitrate, what would you write down for -b:v ? [18:50:00 CEST] <Plebber> Same for a half a megabyte [18:51:44 CEST] <c_14> use 1MiB just to be safe [18:53:11 CEST] <drv> for ffmpeg, -b:v is always in bits, and k == K [18:54:10 CEST] <c_14> * @param numstr a string representing a number, may contain one of the International System number postfixes, for example 'K', 'M', 'G'. If 'i' is appended after the postfix, powers of 2 are used instead of powers of 10. The 'B' postfix multiplies the value by 8, and can be appended after another postfix or used alone. This allows using for example 'KB', 'MiB', 'G' and 'B' as postfix. [18:54:54 CEST] <drv> ah, you're right - didn't know about the B suffix [18:56:02 CEST] <drv> the k/K/M/... multipliers are listed in libavutil/eval.c - si_prefixes array [19:54:20 CEST] <alexpigment> I was working with a TV station today (albeit indirectly) and they accepted 720i MPEG-PS files [19:54:28 CEST] <alexpigment> I had long thought that 720i was a myth [19:54:38 CEST] <alexpigment> Am I wrong? Is this a real standard? [20:09:35 CEST] <kepstin> north america? I don't think it's permitted in ATSC broadcast standards, so they're probably just upscaling it to 1080i [20:12:35 CEST] <kerio> interlaced video is evil [20:21:05 CEST] <leemox> Which mode is better to use for deinterlacing? In bwdif is 2 modes - send_frame and send_field. With the second option, the frame rate is doubled. This is great, but there is not any minuses on image quality? [20:21:31 CEST] <leemox> *video quality [20:21:41 CEST] <leemox> In second option [20:29:03 CEST] <kepstin> leemox: the mode that doesn't double the framerate is basically equivalent to using the mode which does, and then dropping half the frames. [20:29:34 CEST] <kepstin> I think it might be faster, but that's it. no improvement to quality. [20:31:12 CEST] <leemox> So if I understand correctly, it is definitely to take a chance with doubling the number of frames. Thank you :-) [20:31:39 CEST] <kepstin> keep in mind that 30frames per second interlaced video is actually 60 fields per second [20:31:53 CEST] <kepstin> so if you deinterlace and output 30 frames per second, you're losing temporal information [20:33:49 CEST] <leemox> Is there another, better than bwdif deinterlacer in your opinion? [20:33:59 CEST] <leemox> in ffmpeg? [20:34:30 CEST] <kepstin> bwdif is probably the best in ffmpeg, excluding nnedi [20:35:15 CEST] <kepstin> if you want to try nnedi, it might be better to use a different implementation (not ffmpeg) that e.g. supports multithreading, asm optimizations, or even gpu compute. [20:36:55 CEST] <leemox> Nnedi is much better? I know that based on neural networks, but probably not everything that uses something with AI is the best ;-) [20:38:44 CEST] <kepstin> nnedi is an interpolator only, it just guesses what the missing lines are from the current field only. It does do a really good job of this, though. But in some cases, bwdif will give better results. [20:39:29 CEST] <kepstin> state of the art is probably in some of the avisynth scripts/plugins people have done which combine nnedi with motion compensation :/ [20:41:08 CEST] <kepstin> (like furq I've tried mcdeint, but haven't actually seen it do anything useful, and I dunno if I'm doing it right) [20:42:27 CEST] <kepstin> I tend to deal with stuff that's telecined more often than interlaced, tho, so I haven't played around with deinterlacing all that much. [20:43:28 CEST] <leemox> What about nlmeans? [20:44:30 CEST] <leemox> Oups, this is denoise :-) [20:46:39 CEST] <alexpigment> i always use the yadif deinterlacer for what it's worth [20:47:14 CEST] <alexpigment> i haven't done a whole lot of scientific comparisons between bwdif, yadif, or nnedi, but I know that yadif is nowhere near as good as whatever DXVA2 on Windows uses to deinterlace during playback [20:47:34 CEST] <alexpigment> I deal with mostly true interlaced content fwiw, rather than telecined material [20:49:20 CEST] <BtbN> dxva2 uses the hardware deinterlacer of the card [20:50:37 CEST] <alexpigment> BtbN, i thought that might the be case, but I wasn't entirely sure [20:50:44 CEST] <alexpigment> I've always used Nvidia cards for the most part [20:50:57 CEST] <alexpigment> but I've got one HTPC using Intel HD 4600 [20:51:01 CEST] <BtbN> nvidias motion adaptive deinterlacing is quite nice [20:51:13 CEST] <alexpigment> yeah, you can tell they're doing more than just a simple bob [20:51:23 CEST] <alexpigment> (as you'd expect them to) [20:51:45 CEST] <alexpigment> but yeah, I don't think there's anything as nice in ffmpeg to my knowledge [20:51:55 CEST] <alexpigment> I hear that qtgmc is good in avisynth, but I haven't yet tried it [21:12:50 CEST] <harvhat> hello. I'm having some trouble using the amerge filter [21:15:49 CEST] <harvhat> trying to mos 2 stereo sources down to 1 steteo source (ie. -filter_complex "[0][1] amerge" ) but the second source always comes through as mono. I can swap the sources but its always the second source [21:16:25 CEST] <harvhat> *mix 2 stereo sources down to 1 stereo source.. that is [21:22:29 CEST] <kepstin> harvhat: that's not what the amerge filter is for, you probably want to use amix instead. [21:31:24 CEST] <Ingvix> Hey, I've been trying to convert mp4 to mkv while keeping all of the multiple subtitles and audio tracks intact and also adding an additional external sub to the package. It seems that I'm always doing something wrong so could someone just end my suddering and provide an example command where I could learn from? [21:38:33 CEST] <harvhat> kepstin: Okay yes that worked, thanks! I was basing my attempt off the second example under "2 × stereo stereo" on this page in the wiki: https://trac.ffmpeg.org/wiki/AudioChannelManipulation. (the first example works but seems convoluted). "amix" worked perfect a though :) [21:40:04 CEST] <kepstin> Ingvix: can you pastebin the output of "ffmpeg -i file.mp4" on your input? And what format is the external sub file? [21:42:51 CEST] <Ingvix> kepstin, https://pastebin.com/ZMvRKMj7 and the subtitle is in ass format [21:44:21 CEST] <kepstin> Ingvix: alright, something like "ffmpeg -i kimi.mp4 -i kimi.ass -map 0 -map 1 -c copy kimi.mkv" will probably do it, then. [21:45:12 CEST] <kepstin> Ingvix: the "-map" options here say to copy all the streams from input files 0 and 1 respectively, and -c copy means to not attempt re-encoding streams (so the dvd subs will be copied as-is; without that it would probably give an error) [21:49:49 CEST] <Ingvix> kepstin, https://pastebin.com/b9pYFEte I've been getting this error with my previous attempts too [21:50:41 CEST] <kepstin> oh, huh, ffmpeg doesn't want to copy those mp4 'dvd_subtitle' tracks into the mkv eh. [21:52:19 CEST] <Ingvix> I think it'd be okay to convert them if that could make it work [21:52:24 CEST] <Ingvix> to ass of what ever [21:52:27 CEST] <Ingvix> or* [21:52:48 CEST] <kepstin> you could try adding "-c:s:0 dvd_subtitle -c:s:1 dvd_subtitle -c:s:2 dvd_subtitle -c:s:3 dvd_subtitle" to get ffmpeg to run those through its encoder chain, might fix it [21:52:59 CEST] <kepstin> dvd subtitles are images, you can't just "convert" them to a text format :) [21:53:21 CEST] <Ingvix> oh, okay, I try that then [21:56:18 CEST] <Ingvix> does it matter where in the command I add that string? Should it be before -c copy? [21:56:47 CEST] <kepstin> I'd put it after that, but I don't think it would make a difference [21:56:58 CEST] <kepstin> has to be after all the input files and before the output file [21:57:19 CEST] <Ingvix> I see [21:58:04 CEST] <Ingvix> Well now it's processing it. Thanks for your help and explanation [22:05:39 CEST] <Ingvix> Though can I somehow define the language of the new sub? it didn't seem to take it from the file name [22:08:30 CEST] <Ingvix> I found that in documentation. Let's see if I can succesfully use it [22:09:05 CEST] <cbsrobot> Ingvix: should be something like -metadata:s:0 language=eng [22:09:23 CEST] <Ingvix> yes, that's what I found out [22:13:10 CEST] <Dan__> Hi there, I'm having some problems converting DNXHD QT into PNGs. Does anyone here have any experience with this? [22:15:02 CEST] <cbsrobot> Dan__: be more specific [22:24:12 CEST] <Dan__> ffmpeg -i "/Users/Moody/Desktop/PLATES/movieclip.mov" -y -r 24 -vf setsar=1:1 -start_number 1001 "/Users/Moody/Desktop/PLATES/output.%04d.png" [22:25:14 CEST] <Dan__> I'm trying to convert a DNXHD QT into a PNG sequence - the PNGs are coming out looking more crushed than the QT - does anyone know what codec or present I could use to stop this happening, and export a truer PNG representation of the original source file? [22:33:37 CEST] <kepstin> Dan__: please pastebin the *output* of that ffmpeg command [22:33:51 CEST] <kepstin> it has info that we need to know in order to help you (stuff like video codecs, etc) [22:34:07 CEST] <Dan__> Sorry kepstin, how do I do that? [22:34:42 CEST] <kepstin> run the command, copy/paste the text from the terminal onto a pastebin site [22:39:09 CEST] <cbsrobot> Dan__: try: ffmpeg -i "/Users/Moody/Desktop/PLATES/movieclip.mov" -y -start_number 1001 "/Users/Moody/Desktop/PLATES/output.%04d.png" [22:39:27 CEST] <cbsrobot> no need to set sar [22:40:04 CEST] <Dan__> https://pastebin.com/xRpKQq86 [22:41:59 CEST] <Dan__> That didn't seem to work cbsrobot, I got the following error: av_interleaved_write_frame(): Input/output error [22:46:09 CEST] <Mateon1> Hi, is it possible to output a wav file without metadata? I need to pass it into another program, but it has hardcoded offsets and bails out on metadata chunks [22:46:32 CEST] <Mateon1> AKA, the file should only contain the "fmt " and "data" chunks [22:50:05 CEST] <drv> Mateon1: '-fflags +bitexact' should turn off most of the extra metadata chunks, if I remember correctly [23:03:57 CEST] <kepstin> Dan__: are you sure the problem isn't just that your image viewing application doesn't handle 16bit per channel png correctly? :/ [23:05:43 CEST] <Dan__> It's possible, but a colleague who I am working with exported the same QT in PNG format, and the blacks look less lifted than in the version I've managed to get from ffmpeg [23:05:43 CEST] <kepstin> you could try adding -pix_fmt rgb24 so it outputs 8bit per channel png instead, just for comparison [23:06:21 CEST] <Dan__> I had -pix_fmt rgb24 in the code before, but it still generates the same looking QT [23:06:32 CEST] <Dan__> *sorry, the same looking PNG [23:07:03 CEST] <kepstin> note that according to the ffmpeg output, it claims that the input is "tv" (aka limited) range, that could cause issues if it's incorrect. [23:08:24 CEST] <kepstin> if that's wrong, you would see crushed blacks and whites due to clipping on the conversion to rgb. [23:09:38 CEST] <alexpigment> oh man, i've dealt with color/gamut/etc issues in the past. it's a nightmare. sometimes the video card settings are at play, sometimes the application is at play, sometimes (often) it's because the monitor is a wide gamut monitor with a ProPhoto or Adobe 98 color profile. good luck on this one guys :) [23:10:16 CEST] <alexpigment> and yes, full 0-255 vs limited 16-235 is confusing [23:10:27 CEST] <Dan__> I see - is there a way to stop the input being limited? [23:10:52 CEST] <kepstin> this is 10bit, so it's even more confusing (i dunno what the exact ranges are there) [23:10:57 CEST] <alexpigment> yep [23:11:08 CEST] <alexpigment> especially considering most monitors don't actually support 10-bit [23:11:16 CEST] <alexpigment> (or anything above it, obviously) [23:11:26 CEST] <kepstin> Dan__: the issue is that metadata on the input is wrong. I think this can be overridden in ffmpeg, but I forget exactly how, might have to look it up. [23:11:38 CEST] <alexpigment> -color_range full ? [23:11:44 CEST] <alexpigment> i think i remember using that in the past [23:12:10 CEST] <alexpigment> actually, i'm going to do as i said and stay out of this one [23:12:23 CEST] <kepstin> -color_range pc (or -color_range jpeg) as an input option yeah [23:12:42 CEST] <kepstin> have to try and see if it's actually accepted, it says it's just a "hint to the decoder" [23:14:04 CEST] <kepstin> if adding that fixes the issue, then the problem is that whatever made your qt file to start with did it incorrectly :/ [23:20:02 CEST] <Dan__> hmm, it doesn't appear to be working, but I'm still tinkering [23:20:20 CEST] <Dan__> pc or jpeg weren't being accepted, so I had a quick google and think it needs to be either -color_range 1, or -colour_range 2 [23:20:36 CEST] <Dan__> > The source says: > > 0 == unspecified > 1 == "MPEG" range > 2 == "JPEG" range > > Therefore, I'd expect 1 to be "broadcast" 16-235, and 2 to be "full" > 0-255. I haven't tested this, just grepped through the source. [23:20:49 CEST] <kepstin> it should accept those values [23:21:05 CEST] <kepstin> you've only got ffmpeg 2.8 tho, you might want to grab a newer version... [23:21:37 CEST] <Dan__> yes I will do, thanks for your help kepstin [23:21:42 CEST] <kepstin> and what do you mean by "weren't being accepted" - did it actually give an error saying so? [23:21:57 CEST] <Dan__> [png @ 0x7fe2d6802a00] [Eval @ 0x7fff59df6470] Undefined constant or missing '(' in 'pc' [png @ 0x7fe2d6802a00] Unable to parse option value "pc" [png @ 0x7fe2d6802a00] Error setting option color_range to value pc. [23:22:34 CEST] <kepstin> that doesn't make sense... [23:22:51 CEST] <kepstin> are you sure you used it as an *input* option (before the -i)? [23:24:43 CEST] <Dan__> Sorry Kepstin you're absolutely right [23:24:46 CEST] <Dan__> I've just done that and it's worked! [23:24:50 CEST] <Dan__> Thank you so much. [23:25:27 CEST] <Dan__> This will save me hours [23:26:16 CEST] <kepstin> but yeah, this option is just a hack, it says "ignore what the input file claims to be, and treat it as if it was this instead" - it shouldn't be needed on most file. [23:26:47 CEST] <viric> kepstin: I'm aligning things fine and correcting drift. with octave + fftconv + ffmpeg. [23:26:50 CEST] <iive> Dan__: why do you want them as png? [23:30:50 CEST] <Dan__> It's an export from the Avid and we need to work on image sequences in the software we use [23:35:41 CEST] <Dan__> Well as a hack it does exactly what I need - thanks kepstin! [23:36:07 CEST] <Ingvix> Can I convert ass to some image format with ffmpeg? [23:36:27 CEST] <c_14> You con burn it onto a possibly transparent background [23:36:44 CEST] <c_14> so, yeah I guess [23:37:08 CEST] <c_14> You'll lose all timestamp info though (with image output) [23:37:24 CEST] <c_14> use the ass filter (or the subtitles filter) onto a color source with 100% alpha or so [23:38:47 CEST] <Ingvix> it's just that my smart tv does not like to use fonts, colors or positions determined in the ass file so I thought that it they could work if it was in some image based sub format [23:40:20 CEST] <alexpigment> does anyone know why the -standard parameter doesn't work (or what its replacement is)? [23:40:32 CEST] <alexpigment> if i use -tvstd ntsc , it tells me to use -standard instead [23:40:42 CEST] <c_14> Ingvix: you can just burn it onto the video [23:40:56 CEST] <c_14> I'm not entirely sure ffmpeg can convert text subs to video subs though [23:41:03 CEST] <Ingvix> c_14, yes but I don't want to lose the quality [23:41:14 CEST] <Ingvix> of the video [23:41:23 CEST] <c_14> an x264 encode at decent bitrates should be (visually) lossless [23:41:27 CEST] <c_14> unless your source is terrible [23:41:54 CEST] <Ingvix> my source is 16gb hevc 4k [23:42:18 CEST] <Ingvix> uh, the 16gb is just size of the video file but anyway [23:43:12 CEST] <alexpigment> not that it matters really, but content is key here. 16gb for 1 minute of 4k = great quality, 16gb for 2 hours 4k = ok quality [23:43:21 CEST] <alexpigment> er, *context* is key [23:44:09 CEST] <alexpigment> still, c_14's point about being able to encode at something visually lossless is certainly possible, as long as you don't mind large file sizes [23:44:46 CEST] <Ingvix> well it's anime and it's hevc so if I've understood it correctly it got almost twice the bitrate to h264 [23:44:49 CEST] <alexpigment> that said, encoding from hevc to hevc sounds like a bitch [23:44:52 CEST] <Ingvix> or something like that [23:45:00 CEST] <Ingvix> yes, I've done it once [23:45:10 CEST] <Ingvix> and I have those other subs also that I would like to preserve, which are already dvd subtitles [23:46:20 CEST] <c_14> I'm just going to throw this out there, [23:46:28 CEST] <c_14> but just connect an HDMI cable from your computer to the TV? [23:46:57 CEST] <alexpigment> i was just thinking the same thing. or invest in an HTPC that supports Kodi. worth it in the long run imho [23:47:00 CEST] <Ingvix> well, the thing here is that my laptop does not offer 4k over hdmi [23:47:27 CEST] <alexpigment> ingvix does it offer 4k over displayport? [23:47:39 CEST] <Ingvix> it does not have displayport [23:47:43 CEST] <alexpigment> k [23:48:27 CEST] <Ingvix> so creating a good vobsub or what ever out of ass it not possible? [23:48:37 CEST] <c_14> It's technically possible [23:48:58 CEST] <c_14> You could maybe give SubtitleEdit a try [23:49:08 CEST] <Ingvix> I shall [23:49:27 CEST] <c_14> >Export to PNG images (+bdn xml), Adobe Encore FAB image script, VobSub, Blu-ray sup, EBU stl, PAC, and plain text [23:49:36 CEST] <c_14> so should be able to export to VobSub and PGS [23:50:24 CEST] <Ingvix> and ffmpeg is able to attach them to the movie? [23:50:30 CEST] <c_14> yeah [23:50:34 CEST] <c_14> that's the easy part [23:50:39 CEST] <Ingvix> yes, probably [23:51:28 CEST] <Ingvix> also I tried to burn the subs to the file before on this journey to get things right but the output file was only something over 6gb [23:51:48 CEST] <alexpigment> Ingvix: what did you set the crf or bitrate to? [23:51:59 CEST] <alexpigment> and did the quality look noticeably different? [23:52:18 CEST] <alexpigment> sometimes you reach saturation at a lower bitrate. that's especially true with animation [23:52:32 CEST] <Ingvix> I don't think I set anything like that. I didn't even bother to check the quality... [23:52:38 CEST] <Ingvix> but I guess I'm a bit smarter now then [23:52:43 CEST] <c_14> crf 23 probably then [23:53:19 CEST] <Ingvix> but I try the subtitleedit for starters [23:56:31 CEST] <alexpigment> throwing this out there again: [23:56:38 CEST] <alexpigment> does anyone know why -standard doesn't work in FFMPEG? if I use -tvstd ntsc, it tells me to use -standard. if i use -standard ntsc, it says standard is an unrecognized option [00:00:00 CEST] --- Sat Aug 12 2017

1 0