December 2018 - Ffmpeg-devel-irc

ffmpeg-devel.log.20181205
by burek 06 Dec '18

06 Dec '18

[00:03:32 CET] <jkqxz> Other decoders do just write those fields with the stream values directly, as you're observing for MJPEG. [00:03:56 CET] <Sesse> Stream #0:0, 10, 1/1000: Video: mjpeg, 1 reference frame, yuv422p(tv, bt470bg/bt709/iec61966-2-1, progressive, center), 1280x720 [SAR 1:1 DAR 16:9], 0/1, 1k fps, 120 tbr, 1k tbn, 1k tbc (default) [00:04:00 CET] <Sesse> still center :-/ [00:04:10 CET] <jkqxz> (VP9: <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vp9.c;h=acf3ffc9e…>, H.265: <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/hevcdec.c;h=10bf2…>.) [00:04:40 CET] <Sesse> hm, this is odd, even if I remove that setting, it still gets out as cente [00:04:42 CET] <Sesse> r [00:04:57 CET] <thardin> git grep the_thing [00:05:16 CET] <Sesse> wondering if I'm not running the code I expect to [00:05:41 CET] <Sesse> indeed, was running the wrong binary :-) [00:05:42 CET] <Sesse> Stream #0:0, 10, 1/1000: Video: mjpeg (Baseline), 1 reference frame, yuv422p(tv, bt709/bt709/iec61966-2-1, progressive, left), 1280x720 [SAR 1:1 DAR 16:9], 0/1, 1k fps, 120 tbr, 1k tbn, 1k tbc (default) [00:05:46 CET] <Sesse> much better [00:05:58 CET] <Sesse> that's with the conditional setting [00:06:00 CET] <Sesse> and it passes FATE [00:06:45 CET] <thardin> great. now make a FATE test :] [00:07:07 CET] <thardin> so you can be sure your fix doesn't accidentally break in the future [00:10:00 CET] <jkqxz> And maybe change the docs in avcodec.h? This seems quite dubious if decoders are acting in different ways here. [00:10:10 CET] <thardin> that too [00:11:38 CET] <jkqxz> Perhaps an avcodec flag to say "I have colour information from the demuxer, don't overwrite it". That might be a big pain to change if a lot of decoders overwrite it unconditionally, though (small sample suggests they do). [00:12:01 CET] <Sesse> why would you need a flag? [00:12:09 CET] <Sesse> I mean, setting it to something that isn't _UNSPECIFIED is already that flag [00:13:04 CET] <jkqxz> That breaks on a change from foo to unspecified. [00:13:23 CET] <Sesse> no, not really [00:13:24 CET] <jkqxz> And I'm not sure people will want to trust demuxers. [00:13:54 CET] <jkqxz> (Since I bet a lot of things get default values there, too.) [00:14:03 CET] <Sesse> yes, that's a worse problem [00:14:16 CET] <Sesse> although a demuxer shouldn't really [00:14:29 CET] <Sesse> a decoder makes sense, a demuxer doesn't [00:15:49 CET] <jkqxz> That sounds like an argument for the flag being off by default :P [00:16:48 CET] <Sesse> you keep introducing this flag that I don't understand what is supposed to do :-) [00:17:49 CET] <jkqxz> Indicate that the decoder shouldn't overwrite the colour information with whatever it actually finds in the stream, I guess. [00:18:07 CET] <Sesse> and who would set this flag? [00:18:12 CET] <Sesse> the demuxer? the user? the decoder? [00:18:33 CET] <jkqxz> The user. [00:18:37 CET] <Sesse> sounds unlikely to happen [00:18:48 CET] <jkqxz> It would solve your specific problem! [00:19:36 CET] <Sesse> well, so would just overriding the information in avctx directly from my application [00:20:36 CET] <Sesse> it has the exact same set of problems: one would have to know somehow out-of-band when the incoming stream is such a stream, and it won't look right in any video players [00:37:11 CET] <Sesse> ok, patch sent to ffmpeg-devel@, we'll see what happens [01:37:12 CET] <cone-205> ffmpeg 03Michael Niedermayer 07master:09ec182864d4: avcodec/msmpeg4dec: Skip frame if its smaller than 1/8 of the minimal size [01:37:12 CET] <cone-205> ffmpeg 03Michael Niedermayer 07master:d6f4341522c3: avcodec/wmv2dec: Skip I frame if its smaller than 1/8 of the minimal size [01:37:12 CET] <cone-205> ffmpeg 03Michael Niedermayer 07master:953bd58861ad: avcodec/msvideo1: Check for too small dimensions [02:29:49 CET] <philipl> BtbN: did you sign up for the video sdk 9 preview? [10:27:04 CET] <BtbN> philipl, nope, don't really see a point to that. [10:36:50 CET] <durandal_1707> what is about trac maintance it is becoming useless, it is 100% unavailable [15:04:22 CET] <cone-366> ffmpeg 03Gyan Doshi 07master:6ea3cf1b6f18: doc: libmodplug [19:10:14 CET] <durandal_1707> why mxf store width/height aligned to 16? [19:11:03 CET] <JEEB> durandal_1707: does it really? I just thought people liked to include VANC data and then you'd have crop information in MXF [19:11:32 CET] <JEEB> https://github.com/jeeb/ffmpeg/commits/mxf_adventures [19:11:37 CET] <JEEB> I did at some point poke at it [19:14:21 CET] <durandal_1707> michaelni: #5405 is ffv1 bug [19:30:26 CET] <durandal_1707> atomnuker: are you alive? [19:47:51 CET] <atomnuker> durandal_1707: no, I'm merely existing atm [22:13:23 CET] <durandal_1707> atomnuker: doing anything ffmpeg related recently? [22:15:41 CET] <atomnuker> I started writing a music player a week ago but gave up because dbus APIs are undocumented crap and I really wanted a single instance to manage playlists [22:16:42 CET] <atomnuker> and creating random named pipes in /tmp isn't nice [22:16:57 CET] <durandal_1707> atomnuker: that is not ffmpeg related in any way, where is opus fix? where is mdct/fft work? where is vulkan support? [22:17:24 CET] <atomnuker> hey it did use lavf and lavc to decode, I got that much done [22:17:47 CET] <durandal_1707> use mpv with lua, you noob! [22:18:28 CET] <atomnuker> no such extension exists and managing playlists there is uncomfortable [22:19:08 CET] <durandal_1707> nope, you have no skills [22:21:13 CET] <atomnuker> yeah, I could have written a lua script for it, but where's the fun in that [22:22:29 CET] <atomnuker> vulkan support is depending on whether mesa fixes their stuff, since chaining semaphores instead of blocking the pipeline at each stage crashed the gpu [22:23:08 CET] <atomnuker> last I treid in... whenever that was it did that, but maybe now with the recent improvements and support for the dmabuf_modifier extension it all works now [22:23:24 CET] <j-b> 'tsup? [22:25:23 CET] <atomnuker> I think the nicest way to fix opusenc is to change afq to take initial_padding into account, if the initial_padding is indeed what causes the issue [22:28:38 CET] <atomnuker> I'll get around to doing all that, give me a few days to finish hollow knight first, I've held off on playing it since april [22:29:32 CET] <durandal_1707> NOOOOOOO [22:30:54 CET] <j-b> hollow knight is really cool. [22:31:25 CET] <durandal_1707> ony kids play games ^ [22:33:23 CET] <kierank> spiderman is great as well [22:34:22 CET] <durandal_1707> powderman [23:12:26 CET] <cone-339> ffmpeg 03Michael Niedermayer 07master:2c64a6bcd280: avcodec/ppc/hevcdsp: Fix build failures with powerpc-linux-gnu-gcc-4.8 with --disable-optimizations [23:17:04 CET] <ubitux> is it on purpose that yuvrgba gives different result than yuvbgra with sws in bilinear? (after byte swapping) [23:17:19 CET] <ubitux> it doesn't happen with any other interp (bicubic, spline, guauss, whatever) [23:17:41 CET] <ubitux> i need to either disable x86 optims, use +full_chroma_int, or a different interpolation [23:18:16 CET] <ubitux> i'm getting off-by-one most of the time, with a larger diff for green (around off by 2) [23:18:17 CET] <durandal_1707> silly mmx code? [23:18:38 CET] <ubitux> well, it's due to yuv2rgb32_1 apparently [23:19:00 CET] <ubitux> i'm guessing it's related to "note this is not correct (shifts chrominance by 0.5 pixels) but it is a bit faster" [23:19:21 CET] <durandal_1707> ah, lets guess author [23:19:55 CET] <ubitux> note that i'm not even getting why i interpolation has a place here since there is no resize, only resampling [23:20:28 CET] <ubitux> like, i'm surprised to get different always a different result depending on the interpolation i pick [23:20:34 CET] <ubitux> even though i'm doing a yuv2rgb [23:20:55 CET] <durandal_1707> yea [23:20:58 CET] <ubitux> and of course even more surprised to get different results with a different byte swapping [23:21:24 CET] <ubitux> and average of +2 on the green component if i pick rgba or bgra sounds pretty bad to me [23:21:48 CET] <ubitux> michaelni: any idea? [23:24:41 CET] <durandal_1707> just rewrite that code [23:29:41 CET] <nevcairiel> ubitux: afaik sws discards some input chroma samples unless you set one of those mysterious flags, so it treats it like 420 or something and then uses one of its cheap interpolation methods [23:30:00 CET] <nevcairiel> its really full of awful logic [23:30:44 CET] <nevcairiel> +full_chroma_inp would be the flag to preserve full yuv input [23:30:54 CET] <nevcairiel> assuming your image was not subsampled in the first place, of course [23:31:46 CET] <nevcairiel> actually that one is for rgb to yuv [23:31:51 CET] <nevcairiel> the _int one is for yuv to rgb [23:31:53 CET] <nevcairiel> its all dark magic [23:32:15 CET] <nevcairiel> why it would ignore input data is beyond me [23:32:18 CET] <nevcairiel> by default even [23:33:45 CET] <ubitux> yeah that's the flag i mentioned [23:34:05 CET] <ubitux> and the one i'll probably use [23:34:36 CET] <ubitux> the thing is, output are still different with different interpolation [23:34:39 CET] <ubitux> even with that flag [23:34:46 CET] <ubitux> so yeah it fixes my bgra/rgba mismatch [23:34:52 CET] <nevcairiel> your input is 444? [23:34:56 CET] <ubitux> but i'm not sure what interpolation i'm supposed to pick [23:35:07 CET] <ubitux> yuvj440p [23:35:09 CET] <ubitux> (jpg) [23:35:15 CET] <nevcairiel> well rgb is always 444 [23:35:19 CET] <nevcairiel> so that needs some interpolation [23:35:33 CET] <ubitux> mmh ok i see [23:35:37 CET] <ubitux> makes sense [23:35:47 CET] <nevcairiel> how does 440 look again [23:35:52 CET] <nevcairiel> half height i think? [23:35:53 CET] <BtbN> rgb420 when? [23:36:12 CET] <BtbN> who needs green and blue at full res anyway [23:36:14 CET] <michaelni> ubitux, differences between rgba/bgra id say qualify as a bug or at least unintended [23:36:34 CET] <ubitux> i guess you want a repro case / ticket? [23:36:57 CET] <michaelni> i want a patch :) [23:37:09 CET] <ubitux> it's not yet xmas [23:37:13 CET] <ubitux> ;) [23:37:22 CET] <michaelni> np, i can wait ;) [23:37:54 CET] <nevcairiel> a tiny fix patch is all we get for xmas? [23:37:59 CET] Action: michaelni has too many bugs to look into :( [23:38:01 CET] <nevcairiel> I want a better sws with code i can actually understand [23:40:26 CET] Action: jamrial waves at ubitux [23:42:58 CET] Action: ubitux waves back [00:00:00 CET] --- Thu Dec 6 2018

1 0

ffmpeg.log.20181205
by burek 06 Dec '18

06 Dec '18

[00:27:44 CET] <tytyt> Please don't tell me it was this easy: ffmpeg -i image.mp4 test2.webp [00:36:28 CET] <DHE> you get all defaults, which may or may not be what you want. usually the bitrate defaults are kinda poor [02:37:06 CET] <rezonant> (i think my message was blocked cause i didnt identify with nickserv so ill repeat) -- so were getting 'no nvenc capable device' when transcoding an mpeg2 source to h264 -- transcoding mpeg4 -> 264 works just fine -- doesnt seem to matter if we use nvdec for decoding the source file or not, am i missing something? [03:06:58 CET] <DHE> rezonant: you need the binary nvidia drivers installed, and a certain version that is compatible with ffmpeg.... and a suitable GPU, but anything with a fan on it is PROBABLY fine these days... [03:12:01 CET] <furq> if it has gtx in the name and it's less than five years old then you're fine [03:13:12 CET] <rjeli> make sure your NVIDIA drivers are new enough [03:13:26 CET] <rjeli> ffmpeg needs them to be somewhat recent [03:14:08 CET] <rjeli> wow libaom decoding is faster than i expected [03:14:20 CET] <rjeli> real time 1080p hmmmmm [03:26:48 CET] <Hello71> sounds suspiciously fast [03:27:19 CET] <Hello71> isn't libaom fully single threaded? or is it just very poorly threaded [03:28:09 CET] <Hello71> my mistake, aomdec is threaded just poorly [03:56:42 CET] <rjeli> i thought so too [03:58:01 CET] <rjeli> `/ffmpeg -c:v libaom-av1 -i ~/Downloads/Stream1_AV1_HD_2.7mbps$1$.webm -f matroska - | ffplay -` runs real time on laptop i7 [03:58:24 CET] <rjeli> impressive!! [03:59:40 CET] <rezonant> DHE furq rjeli -- we installed the latest drivers and nvenc is working for most transcodes -- problem is our mezzanine is MXF+mpeg2, so ideally we want to go from that to h264 -- other combinations work fine and dont show the "no nvenc capable device" error so i think its just a catchall message in this case [03:59:52 CET] <rezonant> we were sure to specify a pixel format as well on these tests [04:00:28 CET] <rjeli> whats a mezzanine [04:00:38 CET] <rezonant> its a media industry term for "standard format" [04:01:06 CET] <rezonant> its what our editors store the master copies in, mainly to avoid long waits for transcodes on the editor machines (we have beefier machines to do this centrally) [04:02:00 CET] <furq> that sounds fun [04:02:11 CET] <furq> apparently every gpu with nvenc has mpeg-2 decode in nvdev [04:02:15 CET] <furq> nvdec [04:02:24 CET] <rezonant> yeah thats what im seeing, and these are tesla k80s soooo [04:02:28 CET] <rezonant> its not a hardware support issue [04:03:02 CET] <rjeli> uh [04:03:15 CET] <rjeli> one of the nvidia server chips doesnt have nvenc [04:03:30 CET] <furq> this one does [04:03:34 CET] <rezonant> well this one is specifically a server built for transcoding [04:03:36 CET] <rezonant> interestingly, if we dont specify nvdec, it still doesnt work -- you would think ffmpeg would just use software decode to raw, then send the raw to nvenc -- but im not super versed in these bits so maybe thats not how it works [04:03:36 CET] <furq> unless nvidia's website is lying again [04:04:01 CET] <rezonant> obviously im not super concerned about the decode performance with mpeg2 [04:04:07 CET] <furq> rezonant: did you pastebin a command line anywhere [04:04:16 CET] <rezonant> no i can get one though [04:04:24 CET] <rjeli> oh k80s cant decode hevc [04:04:39 CET] <rezonant> yeah but the MXF codec is mpeg2 [04:08:48 CET] <rjeli> ok my last piece of non advice is: sometimes after futzing with nvenc for a few hours and getting inconsistent errors i restart my computer and it works [04:09:01 CET] <rjeli> it is definitely the case that the drivers can go into a bad state [04:11:03 CET] <furq> i find it difficult to believe nvidia drivers would have such poor quality control [04:17:20 CET] <rezonant> https://pastebin.com/d1kL0UZw [04:17:25 CET] <rezonant> ^^ its about as simple as it gets [04:18:50 CET] <furq> i think that should be -pix_fmt yuv420p [04:18:53 CET] <furq> -pixel_format is an input option [04:19:13 CET] <rezonant> oh [04:19:19 CET] <rezonant> hrm lets try that [04:22:31 CET] <rezonant> it says option pixel_format not found -- even though we used -pix-fmt yuv420p .... [04:22:43 CET] <furq> - or _ [04:22:54 CET] <rezonant> sorry -pix_fmt yuv420p is what we used [04:23:01 CET] <furq> is it in the same place [04:24:34 CET] <rezonant> furq -- :-) no [04:24:53 CET] <rezonant> furq you are the best [04:24:59 CET] <rezonant> that was indeed the problem [04:25:19 CET] <rezonant> so -pixel_format is input pixel format and -pix_fmt is the output format [04:25:28 CET] <furq> yeah it's not confusing at all [04:25:30 CET] <rezonant> ah the arcane knowledge of ffmpeg [04:25:52 CET] <furq> you can try -c:v mpeg2_cuvid before -i but idk if that works with 4:2:2 [04:26:02 CET] <furq> m2v decoding in software should be quick enough anyway [04:27:31 CET] <rezonant> yeah indeed, we'll play with the hardware decodes -- furq thanks so much for helping us figure this out -- my colleague and i were slamming our heads at the end of the day today haha [04:53:02 CET] <rezonant> so it looks like the docs are wrong actually [04:53:03 CET] <rezonant> https://trac.ffmpeg.org/wiki/HWAccelIntro#NVENC [10:32:55 CET] <hans_> when trying to load https://trac.ffmpeg.org/wiki/Encode/H.264 i just get a "HTTP 503 Service Unavailable" error [10:38:58 CET] <JEEB> yes, it seems to have been rather heavily loaded since yesterday or so [11:18:15 CET] <alex``> Hi [11:18:34 CET] <alex``> How to get the subtitle format? [11:19:02 CET] <alex``> I would like to automate the extraction of subtitles [11:20:22 CET] <alex``> > ffmpeg -i path/to/video.mkv -map 0:s:{stream} -f srt - 2> /dev/null [11:20:35 CET] <alex``> I would like to know if ass or srt [11:20:45 CET] <alex``> if the video is ass / srt* [11:20:57 CET] <alex``> so that I could do [11:21:34 CET] <alex``> > ffmpeg -i "$file" -map "0:s:$stream" "$directory/$name.$extension" [11:26:47 CET] <ariyasu> i use mediainfo to output the files mediainfo to a txt file [11:26:50 CET] <ariyasu> then greb it [11:26:55 CET] <ariyasu> grep* [11:44:35 CET] <relaxed> alex``: ffprobe -v error -select_streams s:0 -show_entries stream=codec_name -of default=noprint_wrappers=1:nokey=1 input.mkv [11:46:09 CET] <alex``> relaxed: Thanks! [11:46:24 CET] <alex``> What individual switch do? [11:46:51 CET] <alex``> I dont understand ffprobe man @_@ [11:48:49 CET] <hans_> alex``, ffprobe is there to probe a file for information.. what format? codex? compression? streams? ~ [11:50:24 CET] <alex``> is it hans_ which did mvi? ^^' [11:50:46 CET] <hans_> nope, i'm a nobody [11:51:10 CET] <alex``> for example -of default=noprint_wrappers=1:nokey=1, I dont understand this part [11:51:34 CET] <alex``> and -v error [11:52:06 CET] <relaxed> run it without those to see the results [11:52:42 CET] <relaxed> https://trac.ffmpeg.org/wiki/FFprobeTips [11:56:36 CET] <alex``> relaxed: Thanks (3 [11:57:01 CET] <relaxed> alex``: awk is my favorite, though :) ffmpeg -i input.mkv 2>&1|awk '/Subtitle.*(ass|srt)/ {print $4}' [11:59:23 CET] <alex``> I cannot map with ffmpeg subtitles index [11:59:49 CET] <relaxed> pastebin.com what you're doing for help [11:59:54 CET] <alex``> ffmpeg -i give global index (#0.4 for the first subtitles for example) [12:00:39 CET] <alex``> have to go but I will when going back [12:57:52 CET] <hans_> how can i strip the first 10 seconds of audio from a video file? [12:58:12 CET] <hans_> (mp4 to be specific) [13:01:21 CET] <c_14> as in silence that part of the audio? [13:01:34 CET] <hans_> u [13:01:35 CET] <hans_> yes [13:01:44 CET] <hans_> keep the audio, except the first 10 seconds [13:05:01 CET] <c_14> -af volume='if(lt(t,10),0,1)':eval=frame [13:06:12 CET] <c_14> may need escaping, but that should work [13:15:06 CET] <hans_> dang, thanks [13:17:23 CET] <hans_> ffmpeg accepted -af volume=\''if(lt(t,10),0,1)':eval=frame\' - it'll take a while to know if it worked or not tho [13:18:05 CET] <hans_> ... i have no idea what i'm doing tho, does that seem correct-ish? [13:19:27 CET] <ariyasu> you could add like -t 15 before the -i [13:19:53 CET] <ariyasu> then it will only process the first 15 seconds of the video, then you can see if the first 10 seconds are muted [13:20:12 CET] <ariyasu> -t is good for testing before reworking a big file [13:20:56 CET] <hans_> good point, should have done that [13:21:06 CET] <hans_> mhm [13:35:32 CET] <c_14> you can still do it in parallel with a different output file just to test [13:35:46 CET] <c_14> it'll steal a bit of cpu time from the other process but it should be fine [14:06:31 CET] <Zgrokl> Hello what is the thing that make that the audio stream 0:2 goes to default ? [14:06:36 CET] <Zgrokl> and how can i change that ? [14:06:46 CET] <Zgrokl> i taugh default is 0:0 but not [14:27:34 CET] <Zgrokl> ok founded its : -disposition [15:49:25 CET] <e4xit> I have a mixture of FLAC (vinyl rip) files which are 96KHz, 48KHz and 44.1KHz * 32bit, 24bit and 16bit. I would like to recursively pass the folder to FFmpeg to convert them all to ALAC, ideally 44.1KHz/16Bit. Is there a _best_ parameter combination for this, or do I have to trial and error to see which sounds _best_ to me? [15:53:35 CET] <DHE> well the recursive thing isn't something ffmpeg does. you'll have to script it up, maybe find/xargs or such [15:54:51 CET] <e4xit> yes I can do that bit in fish shell, sorry [15:55:39 CET] <Zgrokl> e4xit, go with parrallel for fatest process [15:55:51 CET] <pink_mist> afaik you'll lose information if you transcode to a different bit and khz ... so choosing ALAC seems less than ideal [15:56:00 CET] <pink_mist> but it's your data [15:59:02 CET] <e4xit> bah yeah I know [15:59:44 CET] <e4xit> yeah I know :( seems like advice is to use dithering, and perhaps only resample 96KHz to 48KHz (even multiple)? [16:17:54 CET] <BtbN> Why resample at all? [16:22:16 CET] <e4xit> save 1/3rd space on 150GB of files? [16:22:52 CET] <e4xit> once of the 96KHz 32bit files I reduced to 44.1KHz 16bit was 153MB vs 45MB, I guess it adds up [16:26:24 CET] <e4xit> would a better approach be to keep the sample rate at 96KHz and move to 16bit? This still reduces files size by half using my quick tests [16:28:55 CET] <pink_mist> I mean [16:29:00 CET] <pink_mist> you're losing information [16:29:10 CET] <pink_mist> so there's no point at all in using a lossless codec [16:29:18 CET] <pink_mist> if your goal is to save space [16:29:33 CET] <pink_mist> find a lossy format that's good enough for you. [16:33:03 CET] <e4xit> so it's the same to convert 96KHz 32Bit FLAC to 44.1KHz 16Bit ALAC, as to convert it to AAC 256kbps just because I lose some info each way? [16:35:54 CET] <AsumFace> hello, is there a way to have a filter such as 'select=gt(scene,0.03)' determine the scene change based on a downscaled (or otherwise processed) version of the stream, but pass the selected frames in full resolution forward? [16:36:23 CET] <pink_mist> e4xit: I'd expect so [16:36:36 CET] <pink_mist> e4xit: but you should really compare with your own ears [16:42:33 CET] <e4xit> pink_mist: It seems iTunes can handle 96KHz 24Bit ALAC now, so I will just convert 32Bit to 24Bit using a dither and leave the sample rate alone. Thanks for you help [16:53:03 CET] <Zgrokl> how to only reencode a specific audio stream and copy everything else ? [16:53:16 CET] <Zgrokl> i tried -c:a:4 aac but doesn't work [16:53:38 CET] <kepstin> Zgrokl: "-c copy -c:a:4 aac" or something similar will do it [16:53:55 CET] <kepstin> sets copy mode on all streams, then overrides it on one particular stream [16:54:10 CET] <Zgrokl> command are working but showing : Stream mapping: Stream #0:4 -> #0:4 (copy) [16:54:25 CET] <Zgrokl> he doesn't reencode the 4 stream [16:54:43 CET] <kepstin> probably a typo or option ordering issue. please show us your entire ffmpeg command line. [16:55:32 CET] <kepstin> also note that stream 0:4 is different from a:4 [16:56:06 CET] <Zgrokl> kepstin, : /usr/bin/ffmpeg -i "http://xxx" -map 0 -disposition:a:4 default -disposition:a:1 none -c copy -c:a:4 aac -f mpegts "xxx" [16:56:17 CET] <kepstin> (0:4 means "the fourth track of any type from file 0" and 0:a:4 means "the fourth *audio* track from file 0") [16:57:19 CET] <kepstin> Zgrokl: can you pastebin the ffmpeg output as well please, so I can see the stream mapping? [16:58:09 CET] <Zgrokl> problem seems to be 0:a:4 [16:58:42 CET] <Zgrokl> now it's say invalid encoder type aac, but thats the free lib of aac no ? [16:59:22 CET] <Zgrokl> kepstin, https://pastebin.com/raw/fbJsY29X [17:03:02 CET] <Zgrokl> kepstin, so what is the correct command ? -c:0:4 ? [17:04:48 CET] <kepstin> either -c:0:4 (or just -c:4) or -c:a:1 should work. See https://ffmpeg.org/ffmpeg.html#Stream-specifiers-1 [17:06:42 CET] <Zgrokl> ooooookay now it's working [17:06:58 CET] <Zgrokl> -b:4 120k seems to work too [17:07:02 CET] <kepstin> (hmm I had an off by one error, :4 means the fifth track, because it starts at 0) [17:35:07 CET] <Zgrokl> kepstin, only is now the default audio track is reseted [17:35:25 CET] <Zgrokl> i want to track 0:4 to be the default audio [17:35:39 CET] <kepstin> then fix the stream selectors on your -disposition options too [17:35:40 CET] <Zgrokl> 0 -disposition:a:4 default -disposition:a:1 none or 0 -disposition:0:4 default -disposition:0:1 none [17:35:45 CET] <Zgrokl> doesn't work [17:36:37 CET] <Zgrokl> Ohhhh it's :4 [17:40:32 CET] <devp> Hello, how i could get just the audio on a source from mpeg-dash stream ? I've got the .mpd file with the range of bytes. [18:17:00 CET] <Zgrokl> kepstin, i don't understand i can set none but not default [19:07:47 CET] <jinboli> Hello, I'm working on using hardware acceleration on HD video call. It works well on video resolution lower than 1280x720 but when the resolution gets larger, I got tons of warning from RTP saying "delay reached. need to consume packet""missed -1 packets" It seems the packet is too large so part of the information is missed. Does anyone know how to fix it? [19:17:16 CET] <terminalator> How does one converts multiple flac files to multiple mp3 files? [19:18:39 CET] <furq> you run ffmpeg multiple times [19:18:40 CET] <terminalator> I want to converts a couple of Christmas albums to mp3, but don't want go through the hassle of doing each file manually [19:19:20 CET] <terminalator> furq: Can't I achieve this by simply running one command? [19:19:27 CET] <furq> one shell command, sure [19:19:32 CET] <furq> what os are you on [19:19:59 CET] <terminalator> Xubuntu [19:20:23 CET] <terminalator> furq: A simple bash script is also fine [19:20:42 CET] <BtbN> Just use a for loop oneliner [19:20:42 CET] <furq> for f in *.flac; do ffmpeg -i "$f" -c:a libmp3lame -q:a 0 "${f%.*}.mp3"; done [19:21:14 CET] <terminalator> I thank you kindly gents :) [19:21:14 CET] <furq> also consider using something less ancient than mp3 [19:21:38 CET] <terminalator> furq: What would you suggest? [19:21:51 CET] <furq> opus if your device supports it, otherwise aac [19:22:02 CET] <terminalator> Cool, thanks [19:22:18 CET] <furq> -c:a libopus -b:a 128k [19:22:26 CET] <furq> should be transparent for most stuff [19:24:34 CET] <terminalator> Noice :) [23:40:31 CET] <saml> is there something more reliable than image2? I have image file named without file extension [23:42:50 CET] <furq> the file extension shouldn't make any difference [23:58:54 CET] <TheAMM> You can specify the input codec if you know it and assume it can't be probed [00:00:00 CET] --- Thu Dec 6 2018

1 0

ffmpeg-devel.log.20181204
by burek 05 Dec '18

05 Dec '18

[00:06:19 CET] <Zeranoe> j-b: is that a trick question so I get nailed for distributing? [00:06:35 CET] <j-b> Zeranoe: lol [00:07:01 CET] <j-b> Zeranoe: sharing a link is not distributing, you know that, right? [00:10:00 CET] <Zeranoe> I jest, but are you looking to analyze it something? It just installs with the SDK into NewTek NDI 3.7 SDK\Bin\x86\ffmpeg [00:10:29 CET] <JEEB> just having the binary is enough [00:10:44 CET] <j-b> Zeranoe: yes, to see what x264 version is used. [00:12:52 CET] <Zeranoe> Is there somewhere you'd like me to put it? I don't want it on my site. [00:13:51 CET] <JEEB> the original URL for the download is OK, too [00:13:53 CET] <JEEB> if it still works [00:14:22 CET] <j-b> Zeranoe: it's more for archiving, before people remove it. [00:18:57 CET] <Zeranoe> They use a short URL for downloading the SDK: http://new.tk/NDISDK The 3.7 one brought me here: http://514f211588de67e4fdcf-437b8dd50f60b69cf0974b538e50585b.r63.cf1.rackcd… [00:19:09 CET] <j-b> Zeranoe: thx [00:19:26 CET] <j-b> good. [00:19:46 CET] <j-b> that one is better, because no agreement needed [00:20:23 CET] <Zeranoe> j-b: Yeah, they make you enter an email to get the link. [00:21:46 CET] <Zeranoe> Though, as far as I can tell I'm not agreeing to anything, either in the form or by clicking links in the email. I think they just want to get you on a mailing list [00:21:56 CET] <j-b> ok [00:22:11 CET] <j-b> It's easy also to extract the binary, without agreeing to the license [00:22:44 CET] <j-b> libx264-144.dll [00:22:52 CET] <j-b> thanks. [00:23:50 CET] <BtbN> The Download-Signup-Thing also doesn't work in Firefox [00:23:54 CET] <BtbN> Had to fire up Chrome [00:25:24 CET] <j-b> Zeranoe: does your build dlopen x264? [00:25:47 CET] <BtbN> Does ffmpeg even support that? [00:26:30 CET] <j-b> probably not. [00:26:35 CET] <j-b> i686-w64-mingw32-objdump -x ffmpeg.exe| grep dll [00:26:40 CET] <j-b> DLL Name: libx264-144.dll [00:27:43 CET] <nevcairiel> that sounds like its just a linker entry [00:28:49 CET] <nevcairiel> or if its build with msvc, they could technically enable delay loading just by passing compiler flags [00:29:13 CET] <BtbN> It's MSVC. And I think gcc can do that too [00:29:16 CET] <j-b> nevcairiel: oh really? interesting. [00:29:25 CET] <nevcairiel> its really not a compiler feature as such [00:29:30 CET] <j-b> -DX264_API_IMPORTS [00:29:56 CET] <BtbN> Some tool just automatically builds a static shim lib that delay load on first function use [00:30:09 CET] <BtbN> forgot which one it was [00:30:22 CET] <nevcairiel> yeah i found various tools that do that for linux etc [00:30:35 CET] <j-b> yeah, no. [00:30:37 CET] <nevcairiel> microsoft has that as a standard feature for years now [00:30:47 CET] <j-b> without libx264-144.dll, it does not run at all. [00:30:57 CET] <nevcairiel> yeah then its just linked [00:31:02 CET] <j-b> yup [00:31:08 CET] <j-b> So, they ship x264 too. [00:31:17 CET] <nevcairiel> does that really matter license wise? [00:31:23 CET] <nevcairiel> if i dlopen a dll, its suddenly gpl-ok? [00:31:33 CET] <BtbN> If you don't ship said dll, yes [00:32:29 CET] <JEEB> you might make a case of it if you don't ship it, and the thing clearly wasn't made to be used just with it (or whatever the actual definition of 'derivative work' was) [00:32:47 CET] <JEEB> even if you totally don't distribute libxyz, if the thing clearly needs it to work properly [00:33:18 CET] <j-b> nevcairiel: it depends. [00:33:33 CET] <j-b> BtbN: not always, no. [00:34:07 CET] <j-b> If your software works without the GPL module, and has just "reduced functionality", then it's harder to argue [00:34:19 CET] <j-b> Think of gstreamer GPL modules or dshow plugin. [00:34:51 CET] <j-b> If it does not work, whatever they way, dlopening, linking, soft-linking, activex, delayed-linking, you are a derivative. [00:34:59 CET] <JEEB> yea [00:52:19 CET] <haasn> ^ SVP pretty blatantly violates the GPL of MVTools [00:52:41 CET] <haasn> it absolutely cannot function without being "conveniently" paired up with the open source components of MVTools at runtime by friendly avisynth [00:52:45 CET] <j-b> I am not a huge fan of SVP [00:52:54 CET] <haasn> the author of MVTools knows about this [00:52:58 CET] <haasn> but it's russian so [00:53:01 CET] <j-b> (understatement of the year) [00:54:08 CET] <j-b> anyway, this was good trolling, thanks NewTek [01:10:19 CET] <Zeranoe> How is it decided if it stays or is removed? [03:05:47 CET] <cone-293> ffmpeg 03Lauri Kasanen 07master:78c7ff7d250f: swscale/ppc: Move VSX-using code to its own file [06:11:52 CET] <cone-527> ffmpeg 03Andrey Semashev 07master:f176d6587bcf: lavf/dashenc: Write media trailers when DASH trailer is written. [08:15:07 CET] <JEEB> any comments on the dolby vision identifier patch set? [12:10:15 CET] <cone-756> ffmpeg 03Gyan Doshi 07master:8bd791969960: doc: chromaprint [13:38:02 CET] <cone-756> ffmpeg 03Gyan Doshi 07master:aae7e009b3a9: doc: libgme [15:19:25 CET] <cone-756> ffmpeg 03Martin Vignali 07master:e53901ba5ec3: avcodec/utils : add ff_int_from_list_or_default func [15:19:26 CET] <cone-756> ffmpeg 03Martin Vignali 07master:4141d45ae385: avcodec/prores_aw : add vendor option [15:19:27 CET] <cone-756> ffmpeg 03Martin Vignali 07master:bbbbf237597e: avcodec/prores_aw : only set color prim, trc, space values if supported [15:19:28 CET] <cone-756> ffmpeg 03Martin Vignali 07master:1edaf601f3a2: avcodec/prores_aw : add 4444 xq support [15:46:02 CET] <cone-756> ffmpeg 03Gyan Doshi 07master:ea68e02c6d4f: doc: remove licensing claims for chromaprint and libgme [18:01:21 CET] <durandal_1707> what bug/feature to do now? [18:15:20 CET] <kierank> durandal_1707: fix carl [18:17:17 CET] <atomnuker> lossless jpeg transpose bsf [19:17:37 CET] <kurosu> transpose/rotate 90,180,270/crop [19:29:25 CET] <LigH> Hi. [19:32:08 CET] <LigH> JVET VVC just got ready to be built with MSYS/MinGW too ... so I guess it is not yet in a stage to be considered to be linked into ffmpeg. What would be your criteria to consider this encoder? How would we get to know that you start considering it? Looking for a thread in the mailing list? [19:33:21 CET] <kurosu> please don't do that [19:34:09 CET] <kurosu> let's not have hundreds of versions producing incompatible bitstreams [19:34:24 CET] <BBB> I don't tihnk we've ever linked to models [19:34:33 CET] <kurosu> we already had various versions of hevc's hm, that's enough, thanks.gif [19:34:49 CET] <BBB> youcan use ffmpeg -f rawvideo - | .. to use ffmpeg for decoding and input into vvc software for encoding [19:34:54 CET] <LigH> Aha ... so you will wait for a final bitstream to be announced. Okay. [19:35:03 CET] <LigH> That was my point. [19:35:18 CET] <LigH> No hurry. Just curiosity. [19:35:57 CET] <LigH> With a codec at this complexity, I can imagine to wait rather years than months... [19:36:33 CET] <kurosu> at the very least, don't make producing "invalid" bitstreams so easy that we'll have tickets requesting to support them [19:37:08 CET] <LigH> I remember just a recent case of "final" bitstreams being announced ahead of time. Was it for AV1? :D [19:37:26 CET] <durandal_1707> joke [19:37:32 CET] <LigH> OK, thank you. [19:37:50 CET] <LigH> Bye [19:38:34 CET] <nevcairiel> honestly people should really not care about VVC at this point at all [19:40:46 CET] <jamrial> i'd very much rather people actually started caring about hevc instead, and contributed to ffhevc [19:41:40 CET] <kurosu> need more $ [19:42:25 CET] <kurosu> at this point, h/w decoders are such ubiquituous that almost nobody is interested in that, same for vc1 and vp9 in a way [19:42:32 CET] <kurosu> s/such/so [19:44:17 CET] <jamrial> ffvp9 was done and fully optimized before hw hit the market [19:44:30 CET] <jamrial> so it doesn't matter if nobody cares about software vp9 right now [20:09:00 CET] <durandal_1707> atomnuker: when you gonna finish non-power of 2 dct/fft ? [20:16:51 CET] <JEEB> some comments on the dolby hevc/avc identifiers used with dolby lolvision? [21:08:34 CET] <cone-162> ffmpeg 03Paul B Mahol 07master:ed5680f37ed3: avcodec/dpx: add support for 10bit gray [23:08:08 CET] <BtbN> nvidia claims their turing encoder narrowly beats x264 fast on Turing, comparing PSNR. [23:08:48 CET] <atomnuker> lol [23:10:22 CET] <nevcairiel> that might as well be true [23:10:25 CET] <nevcairiel> just not very meaningful [23:28:35 CET] <philipl> "We can achieve potato quality the fastest" [23:29:39 CET] <nevcairiel> the quality is really not that bad anymore [23:29:45 CET] <nevcairiel> definitely improved over prev gens [23:29:51 CET] <philipl> This is true. [23:29:55 CET] <nevcairiel> just that PSNR is a bad metric [23:30:00 CET] <nevcairiel> but popular nevertheless, unfortunately [23:31:20 CET] <nevcairiel> i've been wanting a new streaming GPU for my media server, I wonder when they'll actually have low-end GPUs with the new media chip [23:31:53 CET] <philipl> Define low-end? The low end pascal had no encode support - only decode. So not much use. [23:31:56 CET] <nevcairiel> as an alternative I could possibly rebuild the server with a Ryzen or so to get higher x264 profile support [23:32:09 CET] <philipl> So it was a 1050 at the minimum if you wanted to transcode. [23:32:15 CET] <nevcairiel> that would be fine [23:33:21 CET] <philipl> Based on past behaviour, I'd expect the better part of a year before we see low end parts. [23:33:46 CET] <philipl> Perhaps it's even more complicated for them now, given that low end parts won't do ray-tracing so how will they brand them? [23:33:56 CET] <nevcairiel> just use GTX again [23:35:39 CET] <nevcairiel> but rebuilding with ryzen would probably be wasted, so probably just wait for a low-end gpu [23:35:52 CET] <nevcairiel> it'll just inherit my current cpu when I rebuild this one in 2020 or so =p [23:36:05 CET] <nevcairiel> whenever icelake vs zen2 are out and about [23:43:37 CET] <BtbN> Something that's not 600¬+ [23:44:02 CET] <BtbN> I also want to get rid of my first gen Ryzen platform. Way too many issues [23:44:25 CET] <BtbN> All but the CPU driven PCIe slots are virtually unusable [23:44:33 CET] <BtbN> The USB controler is a nightmare [23:44:57 CET] <BtbN> It takes 3 to 5 attempts to power on. [23:45:08 CET] <BtbN> "RAM training" [23:46:29 CET] <Sesse> hi. :-) I'm trying to ship MJPEG around with nonstandard chroma (left location instead of center, rec. 709 coefficients instead of 601). I've set it correctly in the mux, but mjpegdec.c just overrides it unconditionally. would a patch that only overrode it if the mux didn't specify it (ie., AVCOL_SPC_UNSPECIFIED etc.) be accepted? [23:47:09 CET] <thardin> probably [23:47:17 CET] <thardin> does it pass FATE? [23:47:26 CET] <Sesse> haven't tried, I'm not sure if I have any way of running FATE tests myself [23:47:29 CET] <Sesse> (never tried it) [23:47:41 CET] <Sesse> I haven't written the patch yet either, I'm trying to get a feel for what my options are [23:47:55 CET] <thardin> you set SAMPLES=some_path then make fate-rsync then make fate [23:47:56 CET] <Sesse> there's the CS=ITU601 hack, but it only specifies TV range, nothing else [23:47:59 CET] <thardin> I think [23:49:17 CET] <thardin> it seems you have the right idea though. maybe someone in here has a different opinion [23:49:48 CET] <Sesse> I guess the counterargument would be that this is so obscure that it's better to just always override [23:50:01 CET] <thardin> maybe. or add an option for it [23:50:05 CET] <thardin> or maintain your own fork [23:50:20 CET] <Sesse> the latter is not really going to fly [23:50:37 CET] <Sesse> I could probably set some private option in the stream, though [23:50:38 CET] <thardin> the way to find out is send a patch in and see if it passes muster :) [23:50:41 CET] <Sesse> :-) [23:50:59 CET] <Sesse> interestingly enough, the mux options are not probed if I set the nobuffer flag [23:51:13 CET] <Sesse> which is a bit odd, but I also really can't find out exactly how much buffering there is without nobuffer [23:51:20 CET] <Sesse> it appears to be mainly related to initial probing [23:52:02 CET] <thardin> there's plenty of weirdness in lavf [23:52:32 CET] <thardin> a few years ago I used to harp on how awful it is [23:54:52 CET] <Sesse> the documentation just says something like turn off the optional buffering [23:54:55 CET] <Sesse> :-) [23:55:06 CET] <jkqxz> I don't think there is a way to pass the colour information in from a demuxer at all? I suspect the easiest answer is to just overwrite the field when it comes out of the decoder. [23:55:38 CET] <Sesse> jkqxz: I'm not sure how to interpret your first sentence, isn't the field set when the decoder runs? [23:56:58 CET] <Sesse> e.g., dnxhd_decode_init has [23:56:59 CET] <Sesse> if (avctx->colorspace == AVCOL_SPC_UNSPECIFIED) { [23:56:59 CET] <Sesse> avctx->colorspace = AVCOL_SPC_BT709; [23:56:59 CET] <Sesse> } [23:57:04 CET] <jkqxz> Yes, the fields are only set by the decoder from the stream it can see. If you have anything from a demuxer then I think you need to apply that separately afterwards. [23:57:16 CET] <Sesse> hm, if so, dnxhd is broken [23:57:34 CET] <thardin> isn't it that demuxers guess, but the real truth is in the decoders? [23:57:45 CET] <thardin> oftentimes it's multiple points of truth [23:57:54 CET] <Sesse> yes, some demuxers can set some of this information [23:57:55 CET] <thardin> and the real truth is in the essence [23:58:04 CET] <Sesse> annoyingly, only matroska seems to really have the full set here [23:58:08 CET] <Sesse> ie., with chroma location and all [23:58:09 CET] <thardin> unless you have customer specific things [23:58:10 CET] <jkqxz> Those fields are all documented as "* - decoding: Set by libavcodec". [23:58:25 CET] <Sesse> interesting [23:58:35 CET] <Sesse> well, compiling now, so we'll see what actually happens in practice, I guess [23:59:00 CET] <jkqxz> That code in dnxhd seems like the condition wouldn't do anything, since the default is UNSPECIFIED anyway? [23:59:16 CET] <Sesse> jkqxz: unless the demuxer already set it? [00:00:00 CET] <jkqxz> Hmm. That doesn't seem to be allowed, but maybe it happens to work anyway for some decoders. Yuck. [00:00:00 CET] --- Wed Dec 5 2018

1 0

ffmpeg.log.20181204
by burek 05 Dec '18

05 Dec '18

[00:02:35 CET] <DHE> if it's valid then I'll take care of it... [00:58:42 CET] <DHE> well, I tried it anyway and it's working.. I guess I'll just chalk it up to forced-IDR weirdness and live with it [02:36:52 CET] <tytyt> I'm trying to convert a png to a raw .y4m, could I get some assistance on how to do that? [02:49:11 CET] <tytyt> This is my current process: ffmpeg -i back.png -pix_fmt yuv420p back.y4m [02:49:14 CET] <tytyt> Is this correct? [04:00:29 CET] <Hello71> seems like you are missing some parameters [04:01:14 CET] <Hello71> huh, it works [04:02:04 CET] <Hello71> not sure why to use yuv420p with rawvideo though [09:11:40 CET] <dv_> iive: I summarized the question here: https://stackoverflow.com/questions/53599205/vc-1-specification-annex-l-wha… [10:43:54 CET] <relaxed> tytyt: ffmpeg -i input -f yuv4mpegpipe out.y4m [11:08:40 CET] <th3_v0ice> Is av_read_frame() a blocking call? Mainly while reading UDP or RTMP streams. [11:09:02 CET] <th3_v0ice> If so how can I make it non-blocking? [11:38:24 CET] <c_14> by default I think so, you can set AVIO_FLAG_NONBLOCK on the format and it will return AVERROR(EAGAIN) instead of blocking [11:38:46 CET] <c_14> may not be supported on all protocols/formats/things though [11:41:10 CET] <c_14> should work for udp and rtmp though [11:41:13 CET] <th3_v0ice> For UDP I set timeout, that solved the problem actally. I am just wondering if that will solve the problem for RTMP, but will need to test. [11:56:04 CET] <vasilica> hello! nice community here [11:57:29 CET] <th3_v0ice> c_14, thanks for the input. I will try to set AVIO_FLAG_NONBLOCK if the timeout fails on RTMP. [11:58:29 CET] <vasilica> a have a quick question, maybe you guys can help me. i have a bunch of audio files (different lengths) and one video of 5 second length. could i use the ffmpeg library to batch convert all the audio files to video files using the 5 second video playing in loop ? [11:59:27 CET] <vasilica> the output video should be the length of the audio file, but with the 5 second video playing as a loop [12:04:19 CET] <c_14> you can try using the -stream_loop option (it's documented in the man pages) [12:04:49 CET] <c_14> that may or may not work depending on the video file, otherwise you can always script it with the concat filter or the concat demuxer and if you're using the C libraries it'll definitely be possible [12:07:18 CET] <vasilica> i will try with the -stream_loop -1 [12:08:40 CET] <pink_mist> you'll also want -shortest [12:08:41 CET] <pink_mist> probably [12:09:39 CET] <c_14> yeah [12:13:27 CET] <vasilica> thanks guys. i'll get on it as soon as i can and i will come back with a feedback, thank you again for the support [13:22:24 CET] <unsymbol> is it possible to specify a video input by name, like you can do with audio interfaces e.g front:CARD=C920,DEV=0, rather than specifying the mount point? [13:33:43 CET] <th3_v0ice> c_14: One more question. If I want to set AVIO_FLAG_NONBLOCK for the input, when should I do that, right after the avformat_open_input()? [13:36:46 CET] <c_14> before the open I'd assume [13:37:24 CET] <c_14> in the open call pass it as one of the flags [13:37:37 CET] <c_14> for avio that is [13:41:13 CET] <th3_v0ice> avformat_open_input() doesnt take any flags, before that method AVFormatContext is null [13:41:29 CET] <c_14> avio_open and avio_open2 do [13:42:04 CET] <c_14> you'd need those for udp/rtmp anyway (unless you do custom IO) afaik [13:42:55 CET] <th3_v0ice> avformat_open_input() is handling the udp and rtmp input just fine, I am however using avio_open for output. [13:43:12 CET] <th3_v0ice> Should I change avformat_open_input() to avio_open() for input also? [13:45:10 CET] <c_14> you can probably set it as an AVDictionary option somewhere [13:47:59 CET] <c_14> th3_v0ice: the AVFormatContext has an avio_flags member [13:48:11 CET] <c_14> you can set that before calling avformat_open_input and it'll get passed to avio_open [13:52:18 CET] <c_14> (you can just allocate one with avformat_alloc_context, set the option and then pass a pointer to it to avformat_open_input if you haven't been manually allocating it already) [13:53:54 CET] <th3_v0ice> I havent, cool! Will try it in a moment. Thanks! [13:57:32 CET] <th3_v0ice> For UDP it still blocks [14:05:18 CET] <c_14> hmm, it should work [14:09:40 CET] <c_14> sounds like a possible bug [14:16:09 CET] <tombb> hi all, I have 3 MTS files, ffprobe says they all have a different "start" time, when I try to merge them to 1 file I lose audio sync, is there any way to RESET the start time to 0? [14:16:48 CET] <th3_v0ice> Let me see if it actually is passed to the avio_open [14:24:42 CET] <th3_v0ice> It seems to be allocated at the start of the method without a check if it already exists. [14:33:41 CET] <dv_> and now I have questions about realmedia / rv30 format specs [14:34:25 CET] <dv_> https://dpaste.de/j34U <- I am trying to make sense of this code snippet from NXP's imx-vpuwrap library [14:35:15 CET] <dv_> I understand that the part in the " if (bIsRV8)" block corresponds to extra data from the realvideo stream [14:35:28 CET] <dv_> but, the "slice info" stuff I cannot find any information about [14:38:52 CET] <c_14> th3_v0ice: that's what the !s && is for [14:39:03 CET] <c_14> if it isn't null it's not allocated [14:46:36 CET] <vasilica> so, i'm back. i've tried mapping the audio to the video and used -stream_loop -1 but it keeps making a video around 69 hours :) [14:47:05 CET] <vasilica> can you please tell what am i doing wrong ? i'm using this command [14:47:50 CET] <vasilica> ffmpeg - i vid.mp4 -stream_loop -1 -i audio.mp3 -map 0:v - map 1:a -c copy output.mp4 [15:07:27 CET] <th3_v0ice> c_14: I am not 100% sure if the second part of the command is not executed if the first logical and fails. [15:08:06 CET] <DHE> in C, the && operator is short-circuiting and will not evaluate further operations if a 'false' comes up on the left side [15:09:13 CET] <DHE> if (X != NULL && *X > 0) // This will not crash whether or not X is NULL [15:09:59 CET] <th3_v0ice> Then I am not sure why solution c_14 suggested doesnt work. [16:23:52 CET] <archibalddd> hello again [17:58:26 CET] <ParkerR> Is there a way to use a video file as the encoding parameters for another video? Say I have fileA thats H264 720x480 1500k. I want to transcode fileB to those same specs (albeit more fine grained than just those 3) [18:00:16 CET] <BtbN> no [18:00:34 CET] <BtbN> for the dimensions it's easily scriptable, but not for any encoder settings [18:00:55 CET] <ParkerR> Ahh ok thanks [18:21:49 CET] <kepstin> if the video was encoded with x264, x264 saves the encoder options used in the file metadata, and you can potentially copy those to encode another video with the same settings [18:22:08 CET] <kepstin> (note that "with the same settings" isn't the same thing as 'to the same specs") [18:23:44 CET] <ParkerR> kepstin, Aye yeah different encoder versions/etc producing slightly different results [18:24:10 CET] <furq> are you concatenating these videos [18:24:25 CET] <furq> it doesn't really matter if you're not [18:24:40 CET] <ParkerR> I'll poke around ffprobe sme more. I'm trying to replace a video in an archive but it may be fruitless anyways since I think the application I'm messing with does checksums [18:24:50 CET] <ParkerR> *some [18:29:59 CET] <ParkerR> So the settings I want to use are Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, smpte170m/bt470bg/bt709), 720x484 [SAR 1:1 DAR 180:121], 1937 kb/s, 25 fps, 25 tbr, 25k tbn, 50k tbc (default) [18:30:27 CET] <ParkerR> And audio Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 125 kb/s (default) [18:39:04 CET] <furq> if you need to match checksums then you've pretty much got no chance [18:40:17 CET] <ParkerR> I know Ill never match checksum [18:40:32 CET] <ParkerR> I just want to get it matching spec wise and Ill see if it does anything afterwards [18:44:38 CET] <kepstin> that's a really weird video size/framerate combination, huh. [18:46:31 CET] <kepstin> but yeah, you'll probably get close enough as to not matter by matching the video resolution/sar/framerate, setting profile to main, and encoding at 2000kbps abr video / 128kbps abr audio (builtin aac encoder will do well enough here) [19:00:32 CET] <tytyt> @Hello71 "not sure why to use yuv420p with rawvideo though" What should I do? [19:04:30 CET] <Hello71> 420 means you lose data [19:05:46 CET] <Hello71> So unless your PNG is 420 (not sure if that's possible) or the input to it was, why not compress [19:06:01 CET] <ParkerR> kepstin, Thanks. Matched all that but the application just doesnt play it. Probbaly doesnt like me messing with the files heh [19:06:51 CET] <ParkerR> It's the little AR video overlay thing. Has an obb file on Android that it validates on launch. You can bypass the launch validation but when it's in the viewfinder it just doesnt play when aimed at the target [19:06:55 CET] <ParkerR> *this little [19:07:11 CET] <ParkerR> Was worth a shot. [19:09:19 CET] <tytyt> Okay that makes sense, what would you suggest? I am trying to compress, 'Keep the best perceived values' [19:10:33 CET] <kepstin> tytyt: what's your final goal? y4m is a container for raw/uncompressed video which is incompatible with 'wanting to compress' [19:11:38 CET] <tytyt> I need to convert it to a format that AOMedia (AV1) can use, and as far as I'm aware y4m is the best format that I can go with to convert. [19:12:01 CET] <furq> that works then [19:12:02 CET] <tytyt> So essentially, I would prefer to convert without compression, [19:12:12 CET] <furq> although you could also build ffmpeg with libaom support [19:12:24 CET] <tytyt> Then handle the quality on AV1 encoding. [19:12:38 CET] <tytyt> Yes, I am just A - B testing right now. [19:14:50 CET] <kepstin> tytyt: you should convert to a pixel format that matches what you want the final encoded av1 video to be in [19:15:30 CET] <kepstin> (and if you're doing any comparisons, you should compare the av1 with the y4m, not with the original png) [19:16:14 CET] <Hello71> although for videos, huffyuv is usually better because most people don't have hundreds of gigs of ram [19:16:41 CET] <furq> aomenc presumably wants y4m input [19:16:44 CET] <furq> otherwise it would be ffmpeg [19:17:27 CET] <Hello71> maybe. how does mkvtoolnix do it? do they have their own demuxers? [19:17:52 CET] <furq> yes [19:17:56 CET] <kepstin> mkvtoolnix contains a set of demuxers and codec parsers, yes [19:18:07 CET] <kepstin> does av1 / aomenv have rgb support at all? or is it yuv only? [19:18:07 CET] <furq> huffyuv would need a decoder as well obviously [19:18:23 CET] <furq> if you're testing av1 then you probably want to do it with yuv420p [19:18:40 CET] <Hello71> also, is there any way to reduce mkv overhead? [19:18:50 CET] <furq> uh [19:18:55 CET] <furq> does it have much overhead [19:19:03 CET] <Hello71> not really [19:19:20 CET] <Hello71> but 1% is 1% [19:19:33 CET] <furq> i've never seen it be 1% [19:19:51 CET] <furq> you can probably mess around with mkvmerge --cluster-length and such [19:22:17 CET] <tytyt> "aomenc presumably wants y4m input" This is correct [19:22:24 CET] <tytyt> It won't convert a png [19:22:55 CET] <tytyt> Technically I want to compare encoding / converting from webp and av1 [21:34:01 CET] <tytyt> Last question, I'm trying to decode (av1) with ffmpeg to webp [21:59:36 CET] <rmbeer> hello [21:59:54 CET] <rmbeer> i have this command: ffmpeg -i /opt/Torrent/3D/3Drender/pre.mkv -i out3.mp4 -lavfi "[0:v]scale=1276:400,setsar=1:1[v1];[1:v]scale=1276:400,setsar=1:1[v2];[v1][0:a:0][v2][1:a:0]concat=n=2:v=2:a=2[outv][outa]" -map '[outv]' -map '[outa]' out4.mp4 [22:00:09 CET] <rmbeer> and get this error: Media type mismatch between the 'Parsed_setsar_3' filter output pad 0 (video) and the 'Parsed_concat_4' filter input pad 2 (audio) [22:00:17 CET] <rmbeer> Cannot create the link setsar:0 -> concat:2 [22:00:28 CET] <rmbeer> no understand how to fix... [22:01:24 CET] <pink_mist> you probably missed something before the concat in the argument [22:01:27 CET] <rmbeer> i want concatenate two video with audio+video [22:01:35 CET] <pink_mist> whether that's a , or a ; or a : or something else I don't know [22:01:41 CET] <pink_mist> but I'd suspect you need one of those [22:01:58 CET] <DHE> 2 video inputs and 2 audio inputs? [22:03:15 CET] <rmbeer> DHE, each file of -i have video and audio, i want concatenate two videos without loss audio and video [22:03:55 CET] <DHE> right, but you're feeding the concatenation 2 inputs, not that each input has 2 video and 2 audio streams [22:05:05 CET] <rmbeer> DHE, no understand... [22:05:45 CET] <rmbeer> each video have two channels of stream, video and audio, i need work with 4 stream, two videos and two audios... [22:05:55 CET] <DHE> https://ffmpeg.org/ffmpeg-filters.html#concat Yes, but v= and a= are setting the number of OUTPUT streams [22:06:32 CET] <rmbeer> ah, i see, thanks [23:04:21 CET] <tytyt> I'm sorry for posting a question twice, but I'm trying to decode a Av1 format .mp4 [ffmpeg -i test.webp -c:v libaom-av1 -crf 43 -b:v 0 -cpu-used 4 -threads 16 -tile-columns 2 -stats -strict experimental image.mp4] and I just want to decode back, could I ask the suggestion on how to achieve this? [00:00:00 CET] --- Wed Dec 5 2018

1 0

ffmpeg-devel.log.20181203
by burek 04 Dec '18

04 Dec '18

[00:37:27 CET] <cone-562> ffmpeg 03Mark Thompson 07master:2f6b1806ce2b: configure: Avoid use of nonstandard features of sed [01:07:57 CET] <cone-562> ffmpeg 03Mark Thompson 07master:21608bc30303: hwcontext_opencl: Use correct function to enumerate devices [01:07:58 CET] <cone-562> ffmpeg 03Ruiling Song 07master:416dc9a5e817: lavf: add transpose_opencl filter [06:40:57 CET] <cone-739> ffmpeg 03Karthick J 07master:0a80b39780c2: avformat/dashenc: Added proper logging when io_open fails for write [06:40:57 CET] <cone-739> ffmpeg 03Andrey Semashev 07master:e444b3b184f3: lavf/dashenc: Write media trailers when DASH trailer is written. [06:40:57 CET] <cone-739> ffmpeg 03Andrey Semashev 07master:a68a97558446: lavf/dashenc: Use avpriv_io_delete to delete files. [06:59:53 CET] <cone-739> ffmpeg 03Karthick J 07master:4bbb6d1ae9e6: Revert "lavf/dashenc: Write media trailers when DASH trailer is written." [07:43:36 CET] <cone-739> ffmpeg 03hwrenx 07master:701cbbb58c76: libdavs2: update api version and enable avx option [07:43:37 CET] <cone-739> ffmpeg 03hwrenx 07master:42597d6fa03c: lavc/libdavs2: output delayed frames [07:43:38 CET] <cone-739> ffmpeg 03hwrenx 07master:8ef0fdaafcf0: lavc/libdavs2: fix function return value error [09:41:30 CET] <j-b> 'morning [10:34:57 CET] <cone-739> ffmpeg 03Paul B Mahol 07master:8440835dbe93: avfilter/vf_overlay: fix filtering with negative y [10:38:28 CET] <CoreX> morning babe [15:32:36 CET] <Zeranoe> So NewTek is providing a non-free copy of FFmpeg in their Windows SDK: https://gist.githubusercontent.com/Zeranoe/8e088a5cab1b33a9a94336f8a23b6be9… [15:44:41 CET] <kierank> Zeranoe: open a ticket [15:45:43 CET] <kierank> they had a copied idct or dct from xvid before [16:13:57 CET] <kierank> funny how they'll try to sue you if you implement NDI yourself [16:14:03 CET] <kierank> but they copy open source code all the time [16:15:30 CET] <Zeranoe> What ever happens with these violations? Does FFmpeg have a legal team I'm not aware of? [17:17:05 CET] <cone-276> ffmpeg 03Paul B Mahol 07master:42d5b59bdcf8: configure: check if dlfcn.h is present for ladspa and frei0r, if not abort early [17:25:23 CET] <durandal_1707> Carl is troll we need! [17:33:47 CET] <cone-276> ffmpeg 03Paul B Mahol 07master:3d8d8c719971: avcodec/r210: use correct pixel format [17:33:53 CET] <Zeranoe> durandal_1707: Context? [17:34:33 CET] <durandal_1707> no context needed [17:35:20 CET] <Zeranoe> Fair enough [19:11:18 CET] <cone-276> ffmpeg 03Carl Eugen Hoyos 07master:be17a82f3cfb: lavc: Bump version for r210 pix_fmt change. [19:30:16 CET] <kierank> j-b: might need you in that thread [19:37:34 CET] <BtbN> Am I missing something in this case? Sure, it's not nice, but out of all the (L)GPL violators, this seems like one of the smaller ones, specially as they have voiced intent to fix it. [19:37:48 CET] <kierank> he hasn't at all [19:37:53 CET] <kierank> he wants people to use his blob with ffmpeg [19:38:07 CET] <kierank> and sues people who independently implement it [19:38:09 CET] <JEEB> and the srt people at least had the decency to open source it [19:38:21 CET] <JEEB> NDI is lol black box [19:39:14 CET] <JEEB> I wonder if we need a rule about not OSI open source nonfree components [19:39:32 CET] <JEEB> as in, if it's not part of the OS and not open source... [19:46:32 CET] <cone-276> ffmpeg 03Paul B Mahol 07master:5487560acfc4: avcodec/dnxhddec: use init_get_bits8() [19:56:49 CET] <gnafu> Boy, they could have a career with the Trump administration the way they lie through their teeth. [19:56:52 CET] <gnafu> "I didn [19:56:58 CET] <gnafu> "I didn't see that post." [19:57:06 CET] <gnafu> [Narrator] "He had." [19:57:23 CET] <gnafu> *cue Arrested Development scene change jingle* [19:57:37 CET] <JEEB> lol [20:15:54 CET] <j-b> kierank: yes, sir? [20:16:02 CET] <kierank> j-b: see NewTek ticket [20:16:40 CET] <j-b> kierank: hmm, I would love to start suing people for FFmpeg violations [20:34:53 CET] <durandal_1707> j-b: you cant sue people, lawyers need millions... [21:17:24 CET] <j-b> durandal_1707: BS. [21:17:32 CET] <j-b> durandal_1707: I sued many VLC GPL violators [22:11:50 CET] <JEEB> any comments on https://patchwork.ffmpeg.org/patch/11258/ and https://patchwork.ffmpeg.org/patch/11257/ [22:24:46 CET] <Fenrirthviti> kierank: Did you have further details on Cross suing someone? Just curious what happened there. [22:26:31 CET] <Fenrirthviti> Rather, making legal threats to be specific. [22:31:01 CET] <kierank> Someone in the OSS community reverse engineered NDI to make an OSS implementation as well as finding many security holes [22:31:07 CET] <kierank> They then got a legal threat [22:32:29 CET] <Fenrirthviti> I see. Nothing public about it, I assume? [22:35:44 CET] <j-b> nope [22:35:50 CET] <j-b> but we could make that public. [22:37:44 CET] <gnafu> I hadn [22:37:55 CET] <gnafu> 't heard of NDI before today, but I'll be sure to avoid it. [22:38:25 CET] <JEEB> wat [22:38:33 CET] <JEEB> carl might want to be a bit more verbose [22:39:11 CET] <iive> what is NDI ? [22:39:15 CET] <BtbN> I also wonder how this would work if they'd have a commercial x264 license, allowing them to do it. Would they have to patch ffmpeg to not display the non-free message? Cause if not for x264, their build could be LGPL and not non-free. [22:39:37 CET] <j-b> What a bunch of BS, they use --enable-nonfree [22:39:44 CET] <iive> don't forget, x264 is dual license [22:40:03 CET] <gnafu> iive: https://en.wikipedia.org/wiki/Network_Device_Interface [22:40:46 CET] <JEEB> BtbN: if the libx264 wrapper is LGPL then maybe (although j-b et al probably have a better view on this stuff) - but there was no hints of that. just enable-gpl and enable-nonfree :P [22:41:21 CET] <BtbN> So only the thin wrapper code would be the issue? wow [22:41:38 CET] <JEEB> I don't know [22:41:56 CET] <JEEB> I think someone here did poink me that LGPL + blob might not be kosher to begin with [22:42:09 CET] <JEEB> as opposed to the "fully LGPL thing being linekd in a blob" [22:42:25 CET] <BtbN> configure allows it at least [22:42:29 CET] <JEEB> because in one case you can get the full source of the open source thing, but having a blob means you have nothing OSS [22:42:38 CET] <JEEB> (within that) [22:42:42 CET] <BtbN> LGPL only requires that you are able to reproduce the build [22:42:51 CET] <BtbN> so you can't statically link, unless you provide your object files [22:42:55 CET] <JEEB> yea, and with the other way it's clear [22:43:17 CET] <j-b> BtbN: if they had, and if the wrapper was LGPL, maybe. [22:43:44 CET] <j-b> BtbN: but I don't think so, since the ndi plugin is not LGPL compatible. [22:44:47 CET] <JEEB> LGPL tends to be much more murky in the way that NDI etc are utilizing it. and j-b f.ex. seems to also have thoughts about that that it might not be kosher at all. [22:45:14 CET] <j-b> JEEB: LGPL is not murky. People want it murky to suit their needs. [22:47:01 CET] <j-b> JEEB: BtbN: do they have a x264 license? [22:47:13 CET] <JEEB> hell if I know. I think BtbN was mostly playing with the idea [22:47:15 CET] <BtbN> You'll have to ask them. I'd guess not. [22:47:26 CET] <BtbN> But that was more in a general sense. [22:50:56 CET] <j-b> JEEB: I do not understand cehoyos answer. [22:51:41 CET] <JEEB> j-b: yea, he was /really/ terse [22:51:48 CET] <JEEB> I would really love it if he was more verbose [22:59:30 CET] <haasn> oh boy [22:59:42 CET] <haasn> I want more info on them trolling OS projects [23:01:13 CET] <j-b> However, if they use x264 without license, I will sue. [23:01:15 CET] <j-b> directly. [23:01:30 CET] <j-b> I really hope for them that they do. [23:02:05 CET] <j-b> This is fun... (not) [23:02:17 CET] <Zeranoe> j-b: Sorry... [23:02:26 CET] <j-b> Zeranoe: why are you sorry? [23:03:06 CET] <Zeranoe> j-b: I reported it [23:03:29 CET] <j-b> Zeranoe: and? [23:03:36 CET] <j-b> Zeranoe: this is great. [23:03:53 CET] <haasn> what country is this copyright violation taking place in? [23:04:32 CET] <j-b> Newtek is making dozen of millions of your work. [23:04:33 CET] <haasn> divided states of capitalism? [23:04:44 CET] <j-b> Zeranoe: you should report more, not less. [23:05:00 CET] <j-b> Zeranoe: you are doing a great job, and they just suck it up from you. [23:05:07 CET] <j-b> and give nothing back. [23:05:42 CET] <atomnuker> were newtek the ones with the really small ibc booth 2 years ago? hard to imagine making millions [23:05:52 CET] <atomnuker> then again if all you do is take other people's work... [23:05:55 CET] <haasn> say you'll believe their genuineness of their apology if they took all of the extra money they earned by enabling x264 in their builds and donated it off to x264 [23:06:10 CET] <j-b> atomnuker: nope [23:06:18 CET] <j-b> atomnuker: they are the ones who had this HUGE booth. [23:06:56 CET] <j-b> atomnuker: https://www.newtek.com/ just look at the footer. This is not a small company [23:07:39 CET] <j-b> They have a branding policy, dozen of trademarks, https://www.newtek.com/trademarks/, they are present on all social networks and active. they have dozen of lines of products. [23:10:25 CET] <Zeranoe> j-b: I took your "not fun" comment too literally I guess. [23:10:38 CET] <j-b> Zeranoe: oops, sorry. [23:10:47 CET] <j-b> Zeranoe: please report more people [23:10:58 CET] <j-b> Zeranoe: I forget IRC is not the best mean to convey the tone. [23:11:16 CET] <j-b> https://www.owler.com/company/newtek estimated number of employees 309, revenue $39M [23:11:19 CET] <j-b> yeah, small company [23:12:09 CET] <Zeranoe> I think all that matters is that they have a legal dept. Small, med, large, if you have legal you lost your excuse. [23:13:12 CET] <atomnuker> ah well, all I remember them for was a crappy usb 2 asi interface card and a usb 3 sdi one [23:13:13 CET] <j-b> Zeranoe: they have one, because they threatened to sue several open source develoeprs. [23:13:28 CET] <j-b> atomnuker: linsys? [23:14:53 CET] <kierank> atomnuker: you are confused with dektec [23:17:36 CET] <kierank> Bellard used to work at dektec [23:17:53 CET] <j-b> oh, yes. dektec, that one is small. [23:18:27 CET] <j-b> JEEB: wtf. [23:19:41 CET] <JEEB> WAT [23:20:37 CET] <j-b> GPL is a contract. [23:22:27 CET] <JEEB> agreed [23:22:55 CET] <durandal_1707> relicense FFmpeg to Public Domain [23:23:05 CET] <j-b> durandal_1707: that could be a good idea. [23:23:25 CET] <Zeranoe> durandal_1707: Many already treat it as much. [23:23:39 CET] <j-b> Zeranoe: that is not normal. [23:23:55 CET] <j-b> JEEB: for example, the way they redistribute the VLC plugin is quite conforming to our license. [23:24:09 CET] <Zeranoe> The more helpful the OSS, the less people care about the license IMO [23:24:11 CET] <j-b> they ship only their plugin, based on the LGPL-only libvlccore. [23:24:27 CET] <j-b> Zeranoe: possible. [23:25:09 CET] <JEEB> yes, if it's just a module that's based on an LGPL lib [23:25:15 CET] <JEEB> then there's nothing special [23:25:48 CET] <BtbN> They didn't link to non-free ffmpeg from their stuff or anything. It's a pre-built ffmpeg.exe with support for their library enabled. Including full insturctions on how to do the same build yourself. So imo the violation is clearly there, but there all the various other violations are of way worse nature. [23:26:27 CET] <BtbN> They can and from the reads of it will just remove those binaries, and no other functionality will be impacted. [23:28:39 CET] <j-b> BtbN: it is a clear violation, from a big company from the sector, that is very agressive against open source developers [23:29:26 CET] <JEEB> these things really don't happen in a vacuum. you can clearly see that effort was put into sticking libx264 there. thus there was a clear reason to think that they wanted to make the thing more useful to potential users ("sell" it better - even in the non-monetary sense). which is all good, the problem is when your stuff is not compatible with being distributed like that. of your volition. [23:29:32 CET] <JEEB> they made the problem for themselves [23:29:33 CET] <BtbN> Is there anywhere I can read up on that case? So far I only heard their side of the story. [23:29:45 CET] <JEEB> yet they want their cake, and eat it too [23:30:55 CET] <BradleyS> public domain is defined by copyright law and such laws are becoming more ridiculous every year and trade agreement [23:31:14 CET] <BradleyS> not that anyone was serious, just saying [23:31:35 CET] <j-b> CC-0 or WTFPL or something, of course. [23:31:54 CET] <BradleyS> sure [23:32:08 CET] <BradleyS> anything well-defined is better than saying "whatever copyright law defines as public domain" [23:32:15 CET] <BradleyS> because that can change [23:32:32 CET] <BradleyS> will someone kindly paste the link to the ticket in discussion [23:34:02 CET] <j-b> of course, the public domain does not exist. [23:35:42 CET] <j-b> Not doing the difference between a server and a USB camera is kind of weird, tbh. [23:36:48 CET] <j-b> BradleyS: I think in France, there is no such definition at all, because you cannot give all your rights. [23:37:16 CET] <j-b> Zeranoe: can you share the binary, please? [23:37:37 CET] <cone-600> ffmpeg 03Paul B Mahol 07master:060ea5261df5: avcodec/r210dec: fix r10x decoding [23:40:44 CET] <BradleyS> ah [23:57:47 CET] <j-b> JEEB: you got my email? [23:58:07 CET] <JEEB> ye [00:00:00 CET] --- Tue Dec 4 2018

1 0

ffmpeg.log.20181203
by burek 04 Dec '18

04 Dec '18

[00:18:23 CET] <atoms118> sorry, had to get some dinner [00:19:45 CET] <atoms118> I'm already using zerolatency and fastdecode [00:20:48 CET] <atoms118> wait I had a syntax issue [00:28:15 CET] <atoms118> ok so it seems ffplay is to blame; "mplayer -benchmark udp://127.0.0.1:1234" is significantly better, with a latency of ~300-400ms, which is still not ideal but much better [00:28:39 CET] <atoms118> however, mplayer takes significantly longer to start up for whatever reason [00:31:25 CET] <atoms118> is there a way to make ffmpeg receive the stream faster? [00:32:10 CET] <atoms118> 400ms is a lot considering it's running over loopback and not even using very much CPU [01:27:19 CET] <BtbN> you'll need to write both player and sender yourself. Generic code is pretty much always optimized for reliability, not zero latency. [05:12:53 CET] <kepstin> and ffplay is designed to be a basic working example player, not to be actually useful for playing. [13:34:00 CET] <skident> Hi there! [13:34:44 CET] <skident> Who knows, how to measure latency of ffmpeg audio filters? Are there any special functions in avfilter library? [15:49:46 CET] <dv_> does anybody know about the sequence layer header in wmv3 RCV headr? [15:50:17 CET] <dv_> in the VC-1 spec (SMPTE 421M), there is the annex.L [15:51:46 CET] <dv_> section L.2 defines the sequence layer, and it mentions a constant byte 0xC5. I am trying to find out what this 0xC5 means. I found in NXP code something about a "codec version" and a "header extension bit". if you combine these two constants in the nxp code, you get 0x85... but I can't find any more info. so, 0xC5 remains a mysterious magical value with no defined meaning except that is has to be there. [17:20:27 CET] <kepstin> dv_: lots of formats have "magic" values that are simply present for format detection or resyncing [17:21:09 CET] <dv_> kepstin: it does not seem to be a "magic" value though [17:21:11 CET] <dv_> https://github.com/genesi/gst-fsl-plugins/blob/master/src/video/vpu_dec.ful… [17:21:37 CET] <dv_> but I cannot find any spec that mentions a "header extension bit" or a "codec version" [18:54:14 CET] <dv_> okay, bit #6 seems to specify whether or not RCV V1 or V2 is used. [18:54:32 CET] <dv_> does anybody know anything about that RCV format that is used for WMV3? I cannot find any spec for it [19:24:46 CET] <JEEB> dv_: I'm not sure who would be the expert on WMVx [19:24:59 CET] <JEEB> probably someone who had been reverse engineering those formats in the past [19:25:14 CET] <JEEB> you'd probably get something out of looking at the history of the wmv3 decoder [19:25:21 CET] <JEEB> but yes, wmv3 had no spec [19:25:25 CET] <JEEB> and the VC-1 one is limited [19:26:25 CET] <JEEB> https://wiki.multimedia.cx/index.php/VC-1 [19:26:44 CET] <JEEB> wmv3 seems to redirect to that [19:31:19 CET] <dv_> wmv3 is pretty much the same as vc-1 main profile [19:31:24 CET] <dv_> so that doesn't surprise me [19:31:38 CET] <dv_> what does surprise me though is that information about RCV is virtually nonexistent [19:32:02 CET] <dv_> the most I found out was from http://www.dre.vanderbilt.edu/~schmidt/android/android-4.0/hardware/qcom/me… [19:32:10 CET] <JEEB> well people were making decoders by reverse engineering the parts that actual available samples were utilizing [19:32:17 CET] <JEEB> at least in open source [19:32:21 CET] <dv_> yea [19:32:30 CET] <JEEB> so if your sample did not utilize any other values you really didn't care about the field [19:33:09 CET] <dv_> oh well, it seems to work well with this info, so I am going to stick to the 0x85 and 0xC5 constants (0x85 for RCV1, 0xC5 for RCV2) [19:39:31 CET] <iive> wmv3 has some "legacy" encoding modes that are not supported by vc1, [22:32:59 CET] <DHE> I'm encoding x264 using the avcodec API. I received a packet with AV_PACKET_FLAG_KEY true, but pts != dts. That's impossible, right? [22:33:10 CET] <DHE> *AV_PKT_FLAG_KEY [22:35:54 CET] <DHE> I should mention I forced the frame to be a keyframe with frame->pict_type=AV_PICTURE_TYPE_I; [22:37:50 CET] <kepstin> if you want it to start a new gop (emit an IDR frame when you ask for an I frame), you need to set the forced-idr avoption. [23:43:00 CET] <DHE> kepstin: yes I did do that [23:43:50 CET] <DHE> I do get the expected keyframe, but this keyframe has dts != pts which I thought was a spec violation or otherwise not valid [00:00:00 CET] --- Tue Dec 4 2018

1 0

ffmpeg-devel.log.20181202
by burek 03 Dec '18

03 Dec '18

[01:07:47 CET] <cone-675> ffmpeg 03Marton Balint 07master:9a39c5449f5a: ffplay: convert float math to int math in calculate_display_rect [01:07:48 CET] <cone-675> ffmpeg 03Marton Balint 07master:418c90faac65: ffplay: fix -x and -y options when only one of them is used [01:07:49 CET] <cone-675> ffmpeg 03Marton Balint 07master:c0479010125b: avdevice/decklink_enc: add support for setting genlock timing offset [04:06:12 CET] <cone-675> ffmpeg 03Jun Zhao 07master:72b047a7a706: lavc/kvazaar: fix auto thread flag in kvazaar wrapper. [12:58:20 CET] <cone-919> ffmpeg 03Martin Vignali 07master:a87ca4bbcab0: avcodec/utils : add YUVA444P12 and YUVA422P12 to pixfmt who need height padding in avcodec_align_dimensions2 [12:58:21 CET] <cone-919> ffmpeg 03Martin Vignali 07master:dae9b4b8a4d9: avcodec/proresdsp : remove unused value [12:58:22 CET] <cone-919> ffmpeg 03Martin Vignali 07master:a97092002601: avcodec/proresdec : move dsp init after codec tag check [12:58:23 CET] <cone-919> ffmpeg 03Martin Vignali 07master:c097a32e93b4: avcodec/proresdec : rename dsp part for 10b and check dspinit for supported bits per raw sample [12:58:24 CET] <cone-919> ffmpeg 03Martin Vignali 07master:9a22e6fa1dec: avcodec/proresdsp indent after prev commit [12:58:25 CET] <cone-919> ffmpeg 03Martin Vignali 07master:1cccf9365df0: avcodec/proresdec : put unpack alpha func in prores ctx [12:58:26 CET] <cone-919> ffmpeg 03Martin Vignali 07master:859604fe9d68: avcodec/proresdec : make inline func for unpack alpha [12:58:27 CET] <cone-919> ffmpeg 03Martin Vignali 07master:fddc92d45479: avcodec/proresdec : add unpack alpha 12 func [12:58:28 CET] <cone-919> ffmpeg 03Martin Vignali 07master:6a583261ea63: avcodec/proresdec : add 12b prores idct [12:58:29 CET] <cone-919> ffmpeg 03Martin Vignali 07master:ffafa53dbf06: avcodec/proresdec : add 12b decoding [14:18:23 CET] <cone-919> ffmpeg 03Carl Eugen Hoyos 07master:3c7a2a0b92e6: tests/ref/fate/vc1test_smm0005: Add a newline. [14:38:16 CET] <cone-919> ffmpeg 03Andrey Semashev 07master:2a5cf8a241e3: lavf/dashenc: Don't put non-mp4 streams in HLS manifests. [14:38:17 CET] <cone-919> ffmpeg 03Andrey Semashev 07master:84c17449ce22: lavf/dashenc: Delete HLS manifests on trailer writing if remove_at_exit is set. [14:45:56 CET] <cone-919> ffmpeg 03kjeyapal(a)akamai.com 07master:6c1e1242012e: avformat/dashenc: Handled the error from dashenc_io_open() [14:45:57 CET] <cone-919> ffmpeg 03kjeyapal(a)akamai.com 07master:c32aad19614c: avformat/dashenc: Added an option to ignore io errors [15:19:36 CET] <cone-919> ffmpeg 03Carl Eugen Hoyos 07master:f7faaa8c187f: Force aix nm to work on 32 and 64 bit binaries by default. [19:23:17 CET] <durandal_1707> finally I kiled trac [19:58:25 CET] <durandal_1707> atomnuker: have you fixed opus bug? some guy named banana man claims that libopus decoder is faster than our native one [20:54:01 CET] <cone-919> ffmpeg 03Andreas Rheinhardt 07master:9f588ba5ca28: cbs_h265: Fix Time Code SEI syntax [20:54:02 CET] <cone-919> ffmpeg 03Andreas Rheinhardt 07master:5d8df52c45b2: trace_headers: Update documentation [22:08:39 CET] <atomnuker> durandal_1707: yeah, no, our decoder is faster [22:08:50 CET] <atomnuker> by a rather large margin too, especially with avx2 [22:10:32 CET] <durandal_1707> guy is full of shit [22:10:52 CET] <durandal_1707> or use celeron cpu [00:00:00 CET] --- Mon Dec 3 2018

1 0

ffmpeg.log.20181202
by burek 03 Dec '18

03 Dec '18

[00:43:11 CET] <multi_io> got it working [02:16:17 CET] <multi_io> well, almost [02:16:42 CET] <multi_io> resulting video plays fine in mplayer, but ffprobe complains "Unsupported codec with id 100359 for input stream 2" [02:17:28 CET] <multi_io> source video was: Stream #0:0: Audio: wmav2 (a[1][0][0] / 0x0161), 44100 Hz, 2 channels, fltp, 96 kb/s Stream #0:1: Video: wmv2 (WMV2 / 0x32564D57), yuv420p, 320x240, 415 kb/s, 24 tbr, 1k tbn, 1k tbc [02:18:19 CET] <multi_io> output video is mp4, no special codec options to ffmpeg [02:20:05 CET] <multi_io> mplayer on the output video (as I said, it plays fine) says [lavf] stream 0: video (h264), -vid 0\n[lavf] stream 1: audio (aac), -aid 0, -alang und\n[lavf] stream 2: subtitle (mov_text), -sid 0, -slang eng [02:21:43 CET] <multi_io> not sure where that subtitle stream came from, there's none in the input video [03:54:37 CET] <poutine> good evening, I love you [04:33:47 CET] <Hello71> nty [06:35:07 CET] <fling> Does opencl help much? What about x264? [16:39:20 CET] <TheWild> hello [16:39:54 CET] <TheWild> any chances to convert ISO/VOB to MKV/whatever without reencoding? [16:42:45 CET] <TheWild> ok, never mind. setting .mp4 file as output worked. I tried .mkv at first thinking it's more universal [16:43:28 CET] <JEEB> both should work [16:48:47 CET] <TheWild> ffmpeg -i 'concat:VTS_01_1.VOB|VTS_01_2.VOB|VTS_01_3.VOB|VTS_01_4.VOB|VTS_01_5.VOB' -c copy /tmp/ramfs/80.mp4 [16:49:00 CET] <TheWild> can't copy the localized audio though :/ [16:49:25 CET] <furq> TheWild: -map 0 [16:50:50 CET] <TheWild> -map 1:a:0 ? [16:51:20 CET] <JEEB> that is a single input as far as I can tell :P [16:51:21 CET] <furq> no, -map 0 [16:51:29 CET] <JEEB> 1 would be the second input [16:51:32 CET] <JEEB> 0th is the first one [16:53:11 CET] <TheWild> ffmpeg -i 'concat:VTS_01_1.VOB|VTS_01_2.VOB|VTS_01_3.VOB|VTS_01_4.VOB|VTS_01_5.VOB' -c copy -map 0:v:0 -map 0:a:1 /tmp/ramfs/80.mp4 [16:53:25 CET] <TheWild> hooray! Thank you JEEB. [16:53:35 CET] <TheWild> you gave me hint what keyword I should search for [16:53:50 CET] <TheWild> oh, furq [16:53:53 CET] <TheWild> JEEB too [17:42:50 CET] <and_> Hello! How can I change the interval ffmpeg (hls) is using to poll live stream m3u8 file? The problem is that it seems to do this every 20sec but my stream requires 10s or the url expires and stream stops. [17:44:16 CET] <JEEB> it should depend on the ext duration [17:44:35 CET] <JEEB> in the HLS playlist [17:47:40 CET] <and_> the second playlist (first has links to playlists with different bitstreams) has #EXT-X-TARGETDURATION:10 (i think it's the needed info, no?) set but seems like it's not honoured [17:50:36 CET] <JEEB> looking at hls.c on master it is supposed to use half of target_duration for reload interval [17:52:28 CET] <JEEB> if you have built FFmpeg yourself I can even tell you how to verify that it did indeed read it :P [17:53:04 CET] <JEEB> also there is a logic that checks the last segment's duration for it as well (supposedly for live playlists under some circuimstances) [17:53:06 CET] <and_> at the moment i'm testing with ffplay version 4.1. when i open the playlist, streams stops ~1min and from logs i can see DEBUG: ffmpeg[70000E597000]: [hls,applehttp] Failed to reload playlist 2 [17:53:51 CET] <and_> but when i create simple loop that pings the playlist url every 10sec witch curl my stream doesn't stop [17:55:42 CET] <JEEB> http://up-cat.net/p/e3430418 [17:56:29 CET] <and_> the link is http://err-egress.cdn.mind.ee/live/etvh/playlist.m3u8 and it should be available now (many shows are geoblocked) [17:57:47 CET] <JEEB> this with an extra message when the badly named parse_playlist gets called http://up-cat.net/p/1f014c11 [17:58:09 CET] <JEEB> (name of function is "parse playlist" while it also goes and gets the playlist then as well) [17:58:58 CET] <JEEB> also I don't think curl by default does keepalive between requests [17:59:08 CET] <JEEB> while the hls "demuxer" does keepalive I think by default [18:03:09 CET] <and_> i use packaged ffmpeg, haven't compiled anything for ages :( [18:04:04 CET] <and_> the server should be wowza and apparently it's enough to fetch the url with your id= every 10sec to keep the stream alive [18:04:44 CET] <Alina-malina> not sure how to fade out with ffmpeg [18:05:16 CET] <Alina-malina> by time, not frame second [18:05:41 CET] <JEEB> and_: you can see if -v debug says anything useful (although you will be getting a *lot* of logging, and I'm not sure how much would be from hls.c) [18:06:07 CET] <JEEB> also you might want to check if `-http_persistent 0` helps [18:06:20 CET] <JEEB> before input, since it's an input option [18:14:16 CET] <and_> JEEB: tried http_persistent but didn't help. the m3u8 url just stops working if not polled every 10s. for example https://err10.babahhcdn.com/live/etvh/index.m3u8?id=35466747366527 is now dead and logtail from ffplay: https://pastebin.com/m8bMm58q [20:02:22 CET] <FishPencil> How should a PSNR be normalized to give a similar result to SSIM (0-1)? [20:35:42 CET] <Alina-malina> anyone? might have idea how to realize fade out at the end of the video with seconds and not frames? [20:36:49 CET] <durandal_1707> Alina-malina: duration/d ? [20:38:00 CET] <Alina-malina> durandal_1707, hmmm is that an option? [20:38:23 CET] <durandal_1707> yes [20:39:06 CET] <Alina-malina> durandal_1707, well this is my command ffmpeg -i wormax11_.mp4 -y -vf fade=out:1900:100 test2.mp4 i could hardly find that 1900 frame, but this is really not convenient for me [20:39:22 CET] <Alina-malina> let me find the usage of duration option, never used that [20:40:07 CET] <durandal_1707> start_time/st too [20:43:33 CET] <FishPencil> So I did a comparison between x265's -preset normal vs. -preset veryslow. The SSIM is only 0.129% different between the two... I know SSIM doesn't tell the whole story, but that doesn't seem worth it for the massively increased computation time. [20:44:35 CET] <furq> ssim doesn't tell much of a story at all for modern video codecs [20:44:43 CET] <furq> you probably want to use vmaf or something [20:44:53 CET] <furq> or your eyes, but that's not ideal if you want numbers as an output [20:46:07 CET] <FishPencil> For PSNR it was like 0.0258% difference between the two. [20:46:29 CET] <furq> psnr is much the same [20:46:39 CET] <FishPencil> I know SSIM/PSNR doesn't tell me much, but I do feel like if it's less than a 1% difference I'm likely not going to visually see that [20:47:28 CET] <furq> they're really not useful metrics at all [20:48:03 CET] <FishPencil> I would say they get you in the same city as the ballpark. [20:48:37 CET] <furq> at least x264 and x265 intentionally distort the input image [20:48:40 CET] <furq> and probably vpx [20:49:21 CET] <furq> you can turn all the psy stuff off with -tune psnr but then you've turned all the psy stuff off so it's not a fair comparison [20:49:59 CET] <FishPencil> I did use the tune option, and I'd assume that without it the visual comparison would be even hard to tell [20:51:15 CET] <FishPencil> For the difference between placebo and ultrafast it was 1.53% different for SSIM [20:51:39 CET] <furq> like i said, vmaf is the only thing in ffmpeg that even claims to be able to give you useful metrics for this [20:52:04 CET] <furq> https://ffmpeg.org/ffmpeg-filters.html#libvmaf [20:52:56 CET] <FishPencil> That's fine and I can try it, but I really doubt it's going to be shocking different like you're suggesting. [20:54:00 CET] <furq> disabling psy makes a noticeable difference to quality [20:54:21 CET] <furq> and i would assume it disproportionately affects the slower presets because they use it more [20:54:28 CET] <furq> it does in x264 anyway [20:55:41 CET] <FishPencil> Are you able to tell the difference between veryslow and normal with x264? [20:57:05 CET] <FishPencil> s/normal/medium [20:57:32 CET] <furq> that's a broad question [20:57:40 CET] <furq> i have noticed the difference before with all other settings being equal [21:10:58 CET] <Alina-malina> durandal_1707, ffmpeg -i wormax11_.mp4 -y -af "fade=out:st=00\:00\:28.0\:d=4" test2.mp4 i am trying this command, but there is no fade on that time :-/ [21:11:48 CET] <durandal_1707> Alina-malina: remove last \ [21:12:12 CET] <durandal_1707> you are escaping duration [21:12:16 CET] <Alina-malina> ok let me try just a second checking [21:14:02 CET] <Alina-malina> still cant see any effect durandal_1707 [21:15:10 CET] <durandal_1707> Alina-malina: pastebin command & full uncut ffmpeg output [21:15:54 CET] <Alina-malina> durandal_1707, https://pastebin.com/raw/Kb7Rfa8i [21:16:22 CET] <FishPencil> furq: Was it blind testing? [21:17:58 CET] <furq> no [21:18:10 CET] <durandal_1707> Alina-malina: you are using very old, >5 years ffmpeg [21:18:23 CET] <furq> i have no confidence i could consistently do it [21:18:31 CET] <furq> i'm just saying psnr and ssim are not good metrics for this [21:18:43 CET] <Alina-malina> oh [21:18:53 CET] <Alina-malina> durandal_1707, ok letme try to upgrade, strange i thought i already ugprade it [21:19:05 CET] <durandal_1707> Alina-malina: also just use seconds for st option [21:19:28 CET] <FishPencil> furq: I'm just saying I don't think they're completely useless and do tell a little of the story. [21:20:25 CET] <FishPencil> furq: It's not like they're going to give <0.1% difference values and in reality the sources are completely distinguishable [21:23:34 CET] <Alina-malina> durandal_1707, same :-/ [21:28:25 CET] <durandal_1707> Alina-malina: pastebin command & full uncut ffmpeg output [21:29:48 CET] <Alina-malina> durandal_1707, https://pastebin.com/raw/2cK58j8h [21:30:56 CET] <durandal_1707> Alina-malina: -vf, -af is for audio [21:31:18 CET] <Alina-malina> oh [21:32:10 CET] <Alina-malina> oh finaly durandal_1707 thank you so much my man! [23:38:39 CET] <atoms118> ok so I'm trying to stream 1080p60 video from a PC to a smartphone real-time for VR purposes; I currently have http://dpaste.com/22KKKC4, however there's still ~1 second of latency [23:39:08 CET] <atoms118> it's running over loopback currently, not actually streaming to my smartphone, so it isn't the network being a bottleneck or anything [23:39:34 CET] <atoms118> I'm not certain whether it's the attached streaming script not working or if ffplay is just really slow at decoding [23:57:10 CET] <furq> atoms118: it should be -tune ultrafast,fastdecode [23:57:28 CET] <furq> er [23:57:33 CET] <furq> -tune zerolatency,fastdecode [00:00:00 CET] --- Mon Dec 3 2018

1 0

ffmpeg-devel.log.20181201
by burek 02 Dec '18

02 Dec '18

[01:50:13 CET] <cone-825> ffmpeg 03Shiyou Yin 07master:5c806d5b54a7: configure: enable mipsfpu for loongson platform. [03:03:33 CET] <cone-825> ffmpeg 03Shiyou Yin 07master:5982614af1f5: avcodec/mips: [loongson] refine optimization in h264_chroma. [03:03:34 CET] <cone-825> ffmpeg 03Michael Niedermayer 07master:7f22a4ebc978: avcodec/truemotion2rt: Fix rounding in input size check [03:03:35 CET] <cone-825> ffmpeg 03Michael Niedermayer 07master:1a89ae1df858: avcodec/hevcdec: Check for overlapping slices [14:10:48 CET] <atomnuker> BBB: having 8/10/12 bit object files and the ability to disable 12 bit considering its almost identical to 10 bit is indeed silly [14:14:24 CET] <atomnuker> I think even having the option to disable high bit depth support is silly and would cause more problems for people who do it, but I'd let them find that out for themselves [14:20:08 CET] <BBB> maybe we should reconsider allowing to disable certain bitdepths [14:20:16 CET] <BBB> it was doable so we did it, but maybe that's not a good argument [14:20:20 CET] <BBB> since even profile 0 has 10bit support [14:22:17 CET] <atomnuker> storage space is cheap, and a megabyte more is a drop in the ocean compared to what browsers weight these days (their fault for shipping an entire OS) [14:22:48 CET] <atomnuker> and given that youtube/netflix/et al want to have HDR which requires highbd browsers have to enable it anyway [14:26:21 CET] <atomnuker> I can't think of anyone who'd have a good reason for disabling it except maybe embedded systems, but like I said storage space is cheap and they'd likely use hardware rather than software [14:49:57 CET] <BBB> file a bug so we remember to remove it [14:49:59 CET] <BBB> or send a patch [19:38:43 CET] <durandal_1707> atomnuker: do you know reason why low-bitrate native opus decoding is worse than libopus one? [19:40:40 CET] <atomnuker> eh? it should be better if anything [19:41:16 CET] <atomnuker> is someone testing from on crappy 2.1 system where the lfe's contents are taken from both channels again? [19:44:47 CET] <durandal_1707> https://0x0.st/sGaA.opus [19:44:58 CET] <durandal_1707> atomnuker: ^ [19:59:17 CET] <cone-675> ffmpeg 03Paul B Mahol 07master:e9967822e412: avcodec: add PCM-DVD encoder [19:59:17 CET] <cone-675> ffmpeg 03Paul B Mahol 07master:2a08faba8802: avformat/mpegenc: extend muxing PCM-DVD to other depths [20:03:25 CET] <atomnuker> looks like sbr is messing it up, I can investigate [20:04:48 CET] <atomnuker> have I mentioned how much I hate what the new opus rfc did or how opus has no proper specs? [20:06:13 CET] <durandal_1707> no [20:09:26 CET] <atomnuker> well, allow me to elaborate, you don't get to break decoding 4 years after the release and say "no no its not breaking, there are now 3 proper ways to decode a file!" [20:10:16 CET] <atomnuker> the old "standard", the new one with the idiotic default of ignoring intensity stereo phase and the new one which does not ignore IS phase [20:11:53 CET] <atomnuker> "standard" is in quote marks because giving a base64 encoded zip file of the reference implementation in an html is a spec is worse than libaom [20:12:32 CET] <atomnuker> reference code is hard to understand, particularly with xiph's coding style, and not even having a rough guideline of what to do doesn't help when you have to RE the code [20:12:36 CET] <nevcairiel> those foss people just cant make standards =p [20:13:09 CET] <atomnuker> well the excuse I was given was that there was just not enough time to make a proper spec, but it could have been done after the fact [20:13:31 CET] <atomnuker> and it would at least confirm and cement what the reference code does (properly or improperly) [20:16:27 CET] <atomnuker> giving people code as a "stadnard" is no different than what all the codecs did in the 90's where the encoder itself was specified so you'd have no freedom to play with anything [20:16:55 CET] <atomnuker> if we had to follow the opus "stadnard" to the dot we'd have to use their resampling code and their mdct [21:10:34 CET] <BBB> "worse than libaom" [21:10:39 CET] <BBB> I will remember that for life [21:14:19 CET] <atomnuker> at least you got a spec with libaom roughly independent of the reference code so you could tell what in essence the reference did [21:14:47 CET] <atomnuker> and you could point to it in case the reference deviated and get an answer which one is correct [21:15:30 CET] <atomnuker> rather than just a vague "whatever the code dose is correct unless we say it isn't in a future version" [21:16:17 CET] <atomnuker> or say "well its correct but so is this new way" [21:17:10 CET] <atomnuker> having multiple ways to decode a file is very uncool [21:18:12 CET] <atomnuker> if aom doesn't version 1.1 bitstreams that would be very uncool too but I think they will [21:18:51 CET] <atomnuker> otoh you can't version opus streams because all packets are valid and there isn't even a single reserve bit [21:20:09 CET] <atomnuker> well there is a way if you signal it in the padding between raw and ec bits, but then you'd need to define state [21:20:56 CET] <iive> atomnuker, is there a way to know which of the 3 standard ways you should use with a given encode? [21:21:07 CET] <atomnuker> nope, all methods are valid for all streams [21:21:16 CET] Action: iive facepalms [21:21:44 CET] <nevcairiel> is the "new" one worse for old files? [21:23:19 CET] Action: iive quadruple facepalms https://static.tvtropes.org/pmwiki/pub/images/stephencolbertquadfacepalm_49… [21:23:33 CET] <atomnuker> yes, I believe so, the sbr changes are better, but if you disable IS sign correction it'll be worse [21:24:10 CET] <atomnuker> (btw the leftover padding bits would be better off used for fingerprinting the same way x264 does) [21:24:47 CET] <atomnuker> it'll slightly violate the spec but any decoder would decode it fine, the same way x264 slightly violates the spec [21:26:57 CET] <kierank> atomnuker: iirc x264 violates the non-normative note [21:27:02 CET] <kierank> to play spec lawyer [21:29:39 CET] <atomnuker> the rbsp_alignment_zero_bit is noted to be non-normatively zero? [21:29:50 CET] <JEEB> kierank: btw I got my first TLV-based sample last week and I'm kind of filled with morbid curiosity still [21:30:21 CET] <kierank> JEEB: tlv? [21:30:32 CET] <JEEB> BT.1869 I think [21:31:05 CET] <kierank> atomnuker: yes [21:31:26 CET] <JEEB> and then you've got the thing that must not be named on top of IP over TLV [21:31:35 CET] <kierank> JEEB: ah GSE? [21:32:41 CET] <JEEB> http://livedoor.blogimg.jp/bs4k8k/imgs/1/3/132ab3d5.png [21:32:51 CET] <kierank> oh dear lord [21:32:54 CET] <kierank> that's fucking insane [21:33:14 CET] <JEEB> yes, that's exactly why parsing that with a hex editor is such a bad activity for a sleepless night [21:33:22 CET] <JEEB> you keep going "I don't believe someoen actually implemented this" [21:33:51 CET] <JEEB> although I guess if you want to believe a receiver is a network interface I guess it makes sense on some level on the TLV/IP layer [21:33:57 CET] <JEEB> what happens after that - less [21:34:56 CET] <kierank> JEEB: main reason ofc is expiring mpegts patents [21:35:00 CET] <kierank> so got to make it more insane [21:35:07 CET] <JEEB> yes [00:00:00 CET] --- Sun Dec 2 2018

1 0

ffmpeg.log.20181201
by burek 02 Dec '18

02 Dec '18

[03:53:06 CET] <No0n3Left> I have a two versions of a video with different audio tracks, however, one has a thing at the begining making the whole thing a bit out of sync with the other. Is there a way to figure out the offset of the video in order to trim the audio so I can mux both audio tracks into one video track so it has two alternative audio tracks that are in sync with the video? [05:16:12 CET] <cheapie> Is there a way to force ffmpeg to read _past_ the duration specified in a file's header? I have an IVF file here with broken metadata - it plays in VLC, but the total length is shown as 00:00. I'm trying to remux it into a new (MKV) container with ffmpeg, but ffmpeg quits as soon as it reaches the indicated length (of 0) and won't actually copy anything over. [05:16:41 CET] <cheapie> This is the command I'm using and the output: https://pastebin.ubuntu.com/p/ZFZqGfBvpn/ [05:19:43 CET] <cheapie> I'm also uploading the file in question, but that will take a while since my connection is pretty bad. [13:12:35 CET] <cocktail> What is the difference between `ffmpeg -i a.mkv -c copy -map 0:2 -map 0:1 b.mkv` and `ffmpeg -i a.mkv -map 0:2 -map 0:1 -c copy b.mkv`? [13:12:56 CET] <cocktail> The outputs of both commands are not exactly the same. [13:14:08 CET] <cocktail> Both commands are supposed to produce the same output. [13:17:38 CET] <cocktail> Should -map come before `-c copy`? [13:17:44 CET] <JEEB> the -c copy is after -i INPUT, and before the output name [13:17:48 CET] <JEEB> so at that point it doesn't matter [13:18:16 CET] <cocktail> Two commands produce slightly different outputs. [13:18:43 CET] <cocktail> Two outputs differ in size by one byte. [13:18:55 CET] <cocktail> One output is one byte larger than the other. [13:18:57 CET] <JEEB> did you actually check with vbindiff or something? [13:19:13 CET] <cocktail> No [13:19:17 CET] <cocktail> But, the size differs. [13:19:39 CET] <JEEB> please do check what the diff is first, and if there's more diff than that :P [13:26:48 CET] <cocktail> JEEB: `ffmpeg -i a.mkv -c copy -map 0 test1.mkv` and `ffmpeg -i a.mkv -map 0 -c copy test2.mkv` don't produce the same file according to vbindiff although test1.mkv and test2.mkv are of the same size. [13:27:08 CET] <cocktail> There are a few differences between two files. [13:27:14 CET] <cocktail> Only a few [13:27:23 CET] <cocktail> Probably timestamps [13:28:09 CET] <cocktail> I'm not sure, yet. [13:28:35 CET] <JEEB> post a bug on trac if it still happens on master [13:29:15 CET] <JEEB> might be minor but it's still weird if ffmpeg.c's (the command line API client) does semi-random differences that are something else than "creation date and tiem" [13:29:23 CET] <JEEB> beceuse those bytes you kind of expect to be updated [13:34:06 CET] <cocktail> For mp3, there is no difference. [13:34:18 CET] <cocktail> For mkv with multiple streams, there are 6 blobs of differences. [13:34:21 CET] <cocktail> 6 short blobs [13:34:40 CET] <cocktail> The mkv has 7 streams. [13:35:40 CET] <cocktail> Probably, different metadata. [13:38:08 CET] <cocktail> I'm going to need a sample mkv. [13:42:19 CET] <JEEB> something like http://www.cccp-project.net/beta/test_files/renderer_test_with_bt709_and_su… ? [13:47:47 CET] <cocktail> The same command produces a slightly different output, depending on when it is executed. [13:48:29 CET] <cocktail> If I swap the position of `-c copy` and `-map 0`, I can locate differences in the same spots. [13:53:02 CET] <cocktail> JEEB: If I executed `ffmpeg -i a.mkv -c copy -map 0 test1.mkv`, `ffmpeg -i a.mkv -c copy -map 0 test2.mkv`, and `ffmpeg -i a.mkv -map 0 -c copy test3.mkv`, then test1.mkv, test2.mkv, and test3.mkv all differ at the same locations. [13:55:36 CET] <cocktail> I guess the order of -map and `-codec copy` doesn't really matter. [13:55:46 CET] <JEEB> sounds more like it [13:56:13 CET] <JEEB> since the options in theory get applied to all inputs/outputs that the apply to, and in theory their order should not matter [13:56:16 CET] <JEEB> within those locations [13:56:32 CET] <JEEB> as in, there's the input and the output paths [13:56:53 CET] <JEEB> those are the things that make a difference regarding positioning [13:57:04 CET] <JEEB> if it's before an input, that's decoding/reading options [13:57:21 CET] <JEEB> if it's after an output, it's encoding/writing options for the output that is coming next [13:57:28 CET] <JEEB> argh [13:57:31 CET] <JEEB> after an input I mean [14:01:34 CET] <cocktail> How does -map affect stream specifiers for -codec? [14:01:57 CET] <cocktail> Are -codec stream specifiers affected by -map? [14:02:05 CET] <cocktail> Are they not? [14:02:21 CET] <cocktail> I don't know whether -map is applied before -codec. [14:02:37 CET] <JEEB> codec is applied after streams have been picked [14:02:40 CET] <JEEB> and map does that [14:02:55 CET] <JEEB> and yes, order of -maps does indeed matter [14:03:11 CET] <JEEB> -map 0:v -map 0:a versus -map 0:a -map 0:v [14:03:24 CET] <cocktail> So, -map affects -codec stream specifiers even if -map comes after -codec. [14:03:40 CET] <JEEB> yes [14:03:58 CET] <JEEB> the order of maps within an output configuration does matter since they seem to get picked as they come [14:03:59 CET] <cocktail> This is making my head spin. [14:24:13 CET] <cocktail> Anyway, I learned a lot today. [14:24:17 CET] <cocktail> Thanks. [15:55:57 CET] <multi_io> is it possible at all to crop a video (e.g. remove a strip at the bottom) without reencoding? [15:56:37 CET] <multi_io> I mean an mpeg video, ideally mpeg 1 through 4 [15:57:34 CET] <JEEB> some formats have cropping info that's used to crop from the closest mod16/64 spot to the resolution needed, but that's quite limited [15:57:42 CET] <JEEB> so if you need more than that, you're SOL [15:58:30 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#mpeg2_005fmetadata [15:58:35 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#h264_005fmetadata [15:58:39 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#hevc_005fmetadata [15:58:45 CET] <JEEB> relevant bit stream filters for those cases [16:30:05 CET] <kepstin> keep in mind that cropping via metadata doesn't actually remove anything from the image, someone could remove the cropping metadata and see the whole thing. [16:54:16 CET] <multi_io> hm, ok [16:56:08 CET] <multi_io> JEEB: kepstin: but actually removing the cropped-out parts without reencoding isn't possible ever? [16:56:25 CET] <JEEB> yup [16:57:09 CET] <JEEB> or well, I'm not 100% sure if you could modify specific macroblocks to just contain a very simple thing, but that's actually N times harder to create then re-encoding [16:57:18 CET] <JEEB> and there's no pre-made tools for that stuff as far as I know [16:57:30 CET] <JEEB> not to mention that if then a future frame uses that macroblock/CTU for prediction [16:57:36 CET] <JEEB> then you suddenly break that too [17:00:09 CET] <multi_io> yeah, I was thinking of cropping along those blocks [17:00:30 CET] <multi_io> I know it works with JPEG ( [17:00:51 CET] <multi_io> (jpegtran can do this if I'm not totally mistaken) [17:00:59 CET] <JEEB> JPEG is really quite a bit simpler [17:38:58 CET] <kepstin> the main issue is that predicted frames might reference data in the cropped out part, i think [17:39:20 CET] <kepstin> so yeah, you can do it with mjpeg and that's about it :) [17:40:14 CET] <kepstin> modern codecs you wouldn't be able to crop stuff in the top/left even if it was I frames only, because of spatial prediction. [17:40:34 CET] <JEEB> yup [17:44:13 CET] <multi_io> ok thanks [18:46:20 CET] <FishPencil> x264 and x265's -preset option is supposed to improve quality/bit. Is there an actual noticeable different between say normal and veryslow? There's certainly a noticeable speed difference. [18:47:20 CET] <JEEB> depends. either do 2pass comparisons with the same target bit rate, or tweak the CRF value until you get the same file sizes for all encoders [18:47:39 CET] <JEEB> and generally, test with bit rates where actual differences would be visible [18:48:08 CET] <FishPencil> I'm using 24 crf with 1080p, so I'd assume that isn't in the noticable range? [18:48:20 CET] <FishPencil> (x265) [18:49:25 CET] <JEEB> I don't even remember what CRF I last used with x265 [18:49:35 CET] <JEEB> also x264 while named similar and have similar features like CRF and presets and tunes [18:49:38 CET] <FishPencil> Defaults to 28 [18:49:39 CET] <JEEB> *x265 [18:49:46 CET] <JEEB> is quite internally different to x264 [18:49:58 CET] <JEEB> so parallels can't be really struck as easily regarding various things [18:50:00 CET] <FishPencil> I'd assume as much with a different spec [18:50:24 CET] <JEEB> but yea, regarding the tests it really doesn't matter as long as you utilize a similar way of getting the result [18:50:37 CET] <JEEB> and that f.ex. you compare the encodes with the same file size in all cases [18:50:41 CET] <FishPencil> Is it safe to assume presets mean less the higher the bitrate/lower the crf? [18:51:01 CET] <JEEB> presets are orthogonal to rate control [18:51:12 CET] <JEEB> preset controls how much time the encoder uses for compression [18:51:24 CET] <JEEB> rate control controls the usage of bits [18:53:41 CET] <FishPencil> Are you aware of any existing studies on how the different presets effect visual quality? [18:54:10 CET] <JEEB> only for the slower presets for x264 I think [18:55:05 CET] <FishPencil> FFmpeg's wiki says that the visual quality will be the same regardless of the preset: [18:55:09 CET] <FishPencil> https://trac.ffmpeg.org/wiki/Encode/H.265 [18:55:32 CET] <FishPencil> I thought the whole point of presets was specifically to control the quality of the encode [18:55:55 CET] <JEEB> yea, that's not exactly correct. what's probably meant is that it's separate from rate control [18:56:07 CET] <furq> if it actually works the same way as x264 then that's wrong, yeah [18:56:31 CET] <JEEB> because if you're bit rate starved and you encode with a slower preset with the same resulting bit rate - your result will be of course better [18:56:42 CET] <JEEB> or at least, if it's not then something's badly wrong [18:57:08 CET] <JEEB> because slower presets are supposed to enable more features and more techniques to squeeze more juice out of the encode [18:59:18 CET] <FishPencil> I might run some psnr tests to see how it effects purely on a metric standpoint. At this point I have no idea if the diff between medium and slow is massive [18:59:45 CET] <JEEB> PSNR/SSIM need their respective tunes to be enabled for the comparison to be valid [18:59:54 CET] <FishPencil> right [19:00:07 CET] <JEEB> because metrics do not equate to visual quality so when you optimize for metrics you disable some psychovisual optimizations [19:00:25 CET] <JEEB> otherwise the metric can go down but your result looks better :P [19:01:42 CET] <FishPencil> They don't equate, but their whole point is to give an idea right? [19:01:52 CET] <FishPencil> They must serve some purpose... [19:02:10 CET] <JEEB> just use the matching tune to your metric when encoding is the bottom line [19:02:32 CET] <JEEB> there's one for psnr and one for ssim in both x264 and x265 if I recall correctly [19:04:24 CET] <FishPencil> Maybe it'd just be better if I did some visual comparisons... [19:32:33 CET] <FishPencil> What's considered the "go to" test media to use? Big Buck Bunny? [19:33:29 CET] <JEEB> derf's collection has various nice stuff https://media.xiph.org/video/derf/ [19:33:52 CET] <JEEB> tears of steel I'd probably use instead of BBB [19:34:13 CET] <JEEB> or some of the Swedish TV's 12 or so year old 4K film samples [19:34:21 CET] <JEEB> that stuff is still some of the best 4K content freely available [19:34:48 CET] <JEEB> SVT_MultiFormat is the keyword for the swedish things [19:35:54 CET] <durandal_1707> FishPencil: anime pr0n [19:39:05 CET] <pagios> hi all, does anyone recommend a reliable ip camera with built in microphone to use for livestreaming conferences? I would like it to be a wireless ip camera that can stream using rtsp with audio and video. something like mevo but more flexible [21:26:02 CET] <nitroxis> When streaming real-time video of the internet, is there any way to tell ffmpeg to drop frames if the upload is stalling/too slow? In my current setup, ffmpeg will keep buffering, probably until it hits a buffer size limit or until the RAM is full. This leads to more and more latency on the receiving end [21:26:10 CET] <nitroxis> over the internet* [21:27:10 CET] <JEEB> you'd probably want to implement that with your own API client [21:27:41 CET] <nitroxis> Ideally, it would detect that it has X unsent frames and drop input frames until the frames are sent [21:27:45 CET] <JEEB> since most likely if you knowingly drop stuff you probably want to reconfigure the encoder to output a random access point :P [21:27:57 CET] <JEEB> oh, dropping on input? [21:27:59 CET] <nitroxis> Well, I'm using the ffmpeg cli tool at the moment [21:28:15 CET] <JEEB> yes, everyone is and at some point you're going to notice it's trying to be a generic tool [21:28:29 CET] <JEEB> and then my recommendation would be to move to making your own API client [21:28:57 CET] <JEEB> personally I'd probably want to separate live and non-live use case API clients [21:29:05 CET] <nitroxis> I know, just thought that maybe it has such an option that I'm unaware of before I'm trying to build my own tool [21:29:07 CET] <JEEB> ffmpeg.c right now is trying to serve so many things at once :P [22:58:54 CET] <multi_io> is there an input option or filter to cut multiple chunks out of the input? I only found -t / -ss for cutting at the beginning/end. [23:00:24 CET] <multi_io> would you use -ss/-t multiple times to create a separate stream for each contiguous segment and then concatenate them again? [23:06:32 CET] <multi_io> looks like using the trim filter multiple times should work [00:00:00 CET] --- Sun Dec 2 2018

1 0