[Ffmpeg-devel-irc] ffmpeg.log.20180503

[burek]

[00:59:30 CEST] <LiedFrice> Does anyone know if ffplay supports full 360 video playback yet? So that one could preview how well sources are being stitched together and such; without having to upload to a service to preview first
[01:00:57 CEST] <JEEB> ffplay is a PoC (Proof of Concept). do not expect it to be a proper player. do note that most likely if you make your manual filter chain you'll be able to play it if libavfilter supports 360 mappings
[01:05:55 CEST] <LiedFrice> I figured as much, I still prefer it to most media players still haha. I'm not certain if libavfilters supports it yet. But if so there's hope I suppose :D
[01:06:29 CEST] <LiedFrice> I love ffplay for its ability to accept piped data versus other media players, too
[01:08:14 CEST] <furq> mpv does that fine
[01:10:23 CEST] <LiedFrice> Didn't know mpv could, thx
[01:14:15 CEST] <LiedFrice> I doubt this is what I want but I found this interesting.  https://github.com/facebook/transform360/blob/master/README.md
[01:14:22 CEST] <LiedFrice> Thanks Facebook
[01:17:44 CEST] <poutine> Is there a way using ffmpeg/ffprobe to get PCR frequency out of a file at rest?
[01:18:35 CEST] <poutine> .ts file
[01:18:38 CEST] <poutine> oops
[01:19:51 CEST] <poutine> we have some automated system complaining about PCR frequency in our mpegts video stream, and I've looked at tstools (both the project with the GUI windows graphing thing, and a loose collection of utilities found on github), and while I do get data out of it, it's not as simple as "PCR packet every 100ms"
[01:28:53 CEST] <Soni> how do I turn /dev/urandom into brown noise?
[01:29:21 CEST] <Soni> cat /dev/urandom | ffmpeg [???]
[01:59:15 CEST] <Soni> and then someone gives me this: `mpv --lavfi-complex='anoisesrc=c=brown [l] ; anoisesrc=c=brown [r] ; [l] [r] amerge [ao]' null://`
[01:59:25 CEST] <Soni> I have no idea what I'm looking at
[02:06:47 CEST] <TheAMM> It creates two sources of brown noise, merges them into a stereo track and opens a null input (since the audio is generated, and not read from a file)
[03:55:29 CEST] <garoto> this is a lazy question and i'm sorry, but what are my options for quality control (bitrate wise) when using "h264_nvenc"?
[03:57:09 CEST] <garoto> (lost my cmd .history file with ~2yrs worth of cli stuff)
[09:37:49 CEST] <greves> Hello, (hopefully) quick question, I am using the following command which works fine to convert a 1080p video to 720p, but it doesn't work for 480p:
[09:38:03 CEST] <greves> ffmpeg -i teaser_raw.mp4 -vf scale=-1:720 -c:v libx264 -crf 24 -preset veryslow -c:a copy teaser_720p_24.mp4
[09:38:23 CEST] <greves> Changing scale to -1:480, I get the following error: [libx264 @ 0x2c9fec0] width not divisible by 2 (853x480)
[09:38:27 CEST] <greves> Should I manually set the width?
[09:39:59 CEST] <jkqxz> Use "-2:480" instead.
[09:40:06 CEST] <greves> What does -2 do?
[09:41:25 CEST] <jkqxz> Ensures that the output is divisible by 2.
[09:42:01 CEST] <greves> Ah great, thank you :)
[09:54:14 CEST] <vishnu_nk> Is there any way to change the program id of a TS stream using ffmpeg?
[09:54:21 CEST] <vishnu_nk> Can anyone help with this?
[10:14:21 CEST] <durandal_1707> not possible
[11:10:40 CEST] <moreentropy> hi
[11:10:57 CEST] <moreentropy> i'm wondering a bit about 48684d26057ad830f522fc94d073a26067b49e6f
[11:11:38 CEST] <moreentropy> i've been using WebM in DASH with 3.4 for a few months now, the commit states that it "has not ever been working"
[11:12:12 CEST] <JEEB> well at least it was crashing until now
[11:12:23 CEST] <JEEB> it could have been broken post-3.4
[11:12:32 CEST] <JEEB> but it was definitely segfaulting and nobody seemed to have used it
[11:12:44 CEST] <moreentropy> yes, it crashes in 4.0 only
[11:12:46 CEST] <JEEB> and since nobody had reported the breakage for months
[11:13:24 CEST] <JEEB> if you -strict experimental does it work for you in a browser etc as well as before?
[11:13:35 CEST] <JEEB> also heh, I guess that akamai dude didn't back-port the fix to 4.0
[11:13:45 CEST] <moreentropy> ok, well I've been (experimentally) using it w/ 3.x for a few months
[11:13:57 CEST] <JEEB> according to the original author from Libav it was tested at some point
[11:14:07 CEST] <moreentropy> doesn't work in a browser right now because it instantly crashes in 4.0
[11:14:30 CEST] <JEEB> well, the crash is already fixed and the crash fix could be back-ported rather easily into the 4.0 branch
[11:14:47 CEST] <JEEB> please try with master and help us verify it. I tried with dash.js I think
[11:15:04 CEST] <JEEB> and IIRC I didn't get it working, although that could've been due to some other reasons
[11:15:16 CEST] <moreentropy> the other commit bad42e9b40920f079b27e5bd4103d9293046b2ed is great, I wanted to submit a similar patch, with ctx->strict_std_compliance = s->strict_std_compliance
[11:15:26 CEST] <moreentropy> I'll do that!
[11:16:06 CEST] <JEEB> I will probably add a new thing that lets you pick the format
[11:16:11 CEST] <moreentropy> I'm also experimenting with flac in dash/mp4, works fine but has an issue with the dash manifest (will submit a but for it)
[11:16:14 CEST] <JEEB> since right now you can't get WebM with VP9 for example
[11:16:31 CEST] <JEEB> since the akamai dude "changed the default"
[11:16:39 CEST] <JEEB> at which I yelled a bit on the internet
[11:16:46 CEST] <JEEB> because defaults mean there are alternatives
[11:16:52 CEST] <JEEB> while in this case it just switched the container
[11:23:09 CEST] <JEEB> moreentropy: feel free to join the -devel channel and share your results there
[11:23:39 CEST] <JEEB> as you get them, that is
[11:25:43 CEST] <moreentropy> JEEB: will do, thanks. building right now..
[11:27:27 CEST] <JEEB> I guess "working" would be chromium and firefox at the very least
[11:27:36 CEST] <JEEB> so if the WebM output works on those, we can consider it OK
[11:28:00 CEST] <JEEB> (you might have to revert the VP9 change to get WebM for it)
[11:34:20 CEST] <moreentropy> I'm using audio only for DASH streams at a radio station, so didn't try / not affected by VP9 in WebM problems
[11:34:51 CEST] <JEEB> ah
[11:35:04 CEST] <JEEB> well, still - we found a user \o/
[11:35:05 CEST] <moreentropy> tested with chrome desktop and mobile, firefox, edge
[11:35:11 CEST] <moreentropy> works in all three
[11:35:51 CEST] <JEEB> ok, can you test with vp9 and vp8 video? I think vp9 now should write the profile string in the manifest so the manifest side should work in chromium and firefox
[11:35:55 CEST] <JEEB> (and probably edge)
[11:35:59 CEST] <moreentropy> haha. yeah i'm experimenting a lot with chunked streaming, our default live streams to the browser are progressive download / icecast right now and i want to change that
[11:36:00 CEST] <JEEB> but if they support WebM at all
[11:36:27 CEST] <moreentropy> yes, can try that later today
[11:36:33 CEST] <JEEB> yea, to be honest I prefer long connections for streaming but browsers can't do that without extra complexity
[11:36:51 CEST] <JEEB> which is why web people mumble about websockets etc
[11:38:13 CEST] <moreentropy> we had a lot of trouble with antivirus that tried to intercept, download and scan the streams before giving data to the browser
[11:38:24 CEST] <moreentropy> switching to HTTPS made that go away
[11:38:34 CEST] <JEEB> lol
[11:40:10 CEST] <moreentropy> DASH seems really solid, streams start instantly, the client can decide how close to the live edge it will go (afaik). tried listening to a DASH/WebM/OPUS stream with three qualities during a 40 minute commute to work w/ mediaelemend.js on chrome on android
[11:40:40 CEST] <moreentropy> the stream switched qualities multiple times and i had a short data outage, live stream continued a the live edge when data came back
[11:41:55 CEST] <moreentropy> but I have to resample (async=1) the alsa input, else the stream will slowly drift over days and will not start instantly in the browser because timestamps don't match (???)
[11:43:47 CEST] <moreentropy> with flac in dash/mp4 the manifest says codecs="fLaC" which the browser doesn't accept, I filtered fLaC -> flac in Nginx, now it works flawlessly. will open a trac for it
[11:49:15 CEST] <JEEB> ok, also try poking the webm mode for it (I don't think it's set to get WebM by default)
[11:56:10 CEST] <moreentropy> yeah afaik flac/mp4 is defined somehow while flac/webm is not (??), but I really don't know the details.
[11:57:04 CEST] <moreentropy> basically this works with ffmpeg https://www.bbc.co.uk/rd/blog/2017-04-radio-3-high-quality-flac-dash
[11:57:40 CEST] <moreentropy> experimental live stream w/ ffmpeg: https://www.eldoradio.de/broadcast/flac/
[12:22:54 CEST] <JEEB> moreentropy: flac/webm is just matroska. same as opus
[12:23:09 CEST] <JEEB> so in theory it should be even more defined than ISOBMFF ;)
[13:33:47 CEST] <dsi> Hi everyone, I am having some trouble getting the dev packages for FFMPEG libraries such as libavcodec on a Debian 9 (Stretch). When I use aptitude or apt-get, I get  an "unmet dependencies" error
[13:34:39 CEST] <dsi> For example, for libavcodec-dev, I get "libswresample-dev : Depends: libswresample2 (= 7:3.2.9-1~deb9u1) but 7:3.2.10-1~deb9u1 is installed" .... I have all the runtime libraries
[13:37:05 CEST] <Blacker47> dsi, is more a debian-related question. also it should depend on the .10-1.. version like here (tested). so you may need to update your sources first (e.g. apt-get update) or check if you have right sources enabled.
[13:42:09 CEST] <dsi> blacker47: Thanks, I will try that out.
[15:53:09 CEST] <arinov> guys
[15:53:14 CEST] <arinov> ffmpeg -framerate 30 -f x11grab -i 0 test.flv
[15:53:17 CEST] <arinov> does not work
[15:53:24 CEST] <arinov> [x11grab @ 0x55cf3ca087c0] Cannot open display 0, error 5.
[15:53:27 CEST] <arinov> 0: Input/output error
[15:53:33 CEST] <arinov> i have 3 displays here
[15:53:44 CEST] <arinov> trying to record from one of them
[15:53:59 CEST] <atomnuker> use kmsgrab if you can, its faster
[15:54:24 CEST] <atomnuker> you need either vaapi support or opencl
[15:54:38 CEST] <arinov> nknown input format: 'kmsgrab'
[15:54:47 CEST] <arinov> i am on fedora 27
[15:54:54 CEST] <arinov> ffmpeg from rpmfusion
[15:55:38 CEST] <JEEB> x11grab probably won't work with wayland :)
[15:55:48 CEST] <JEEB> and for kmsgrab you then need to build yer own FFmpeg
[15:55:58 CEST] Action: JEEB actually likes Fedora because standard repositories come without FFmpeg et al
[15:57:01 CEST] <arinov> i am sure i am on X (configured GDM)
[15:57:39 CEST] <debianuser> arinov: `-i :0` maybe?
[15:57:46 CEST] <arinov> WaylandEnable=false in gdm custom.conf
[15:58:00 CEST] <debianuser> arinov: echo $DISPLAY
[15:58:18 CEST] <arinov> debianuser: works
[15:58:20 CEST] <arinov> :1
[15:58:21 CEST] <arinov> thanks
[15:58:46 CEST] <arinov> lol
[15:58:58 CEST] <arinov> it writes the left screen (part of it)
[15:59:19 CEST] <arinov> it seems i have on big screen here in gnome
[16:01:08 CEST] <JEEB> arinov: the Xorg GNOME shell is an option in the graphical interface of gdm anyways, so in theory you don't need to poke at config files
[16:13:15 CEST] <arinov> $ ffmpeg -video_size 1920x1080 -framerate 30 -f x11grab -i :1+1080,0 test.flv
[16:13:17 CEST] <arinov> perfect
[16:14:19 CEST] <arinov> left & right screens are in vertical orientation, central in horizontal
[16:14:36 CEST] <arinov> making screencast from central with this options
[16:38:29 CEST] <easy_ref123> can't find a description of the -b flag in the manpage
[16:38:33 CEST] <easy_ref123> somebody?
[16:39:17 CEST] <crypttab> easy_ref123: it's the bitrate in kbits/s
[16:40:52 CEST] <TheAMM> Bits, not kbits
[16:42:27 CEST] <TheAMM> It's also technically unique per-encoder, not a global option, but pretty much all encoders have a -b option to set a bitrate in bits/s
[16:44:19 CEST] <crypttab> TheAMM: true, thanks
[16:45:20 CEST] <furq> easy_ref123: https://www.ffmpeg.org/ffmpeg-codecs.html#Codec-Options
[16:58:41 CEST] <JEEB> TheAMM: there are options in the AVCodecContext, and those are global
[16:58:50 CEST] <JEEB> the bit rate thing is in AVCodecContext
[16:58:58 CEST] <JEEB> so it 100% bases on if the encoder reads it or not
[16:59:04 CEST] <JEEB> instead of "is it there or not"
[16:59:30 CEST] Action: TheAMM shrugs
[16:59:41 CEST] <TheAMM> I can't find -b on the general options manpage
[16:59:47 CEST] <TheAMM> Only on codecs
[17:00:37 CEST] <DrLuke> Hello, where can I read how the pixel data in AVFrame is structured? I'm asking because I'm converting to RGB24 and I am wondering if it gives me the data in 3 seperate arrays for each channel or just one
[17:02:33 CEST] <atomnuker> no, RGB24 is interleaved packed RGB, so everything is in AVFrame->data[0]
[17:05:24 CEST] <DrLuke> atomnuker: so it's [R G B R G B ...] ?
[17:05:45 CEST] <DrLuke> That's actually exactly what I need :D
[17:06:39 CEST] <DrLuke> Thank you :)
[17:10:10 CEST] <atomnuker> each pixfmt has a comment describing its layout in libavutil/pixfmt.h
[17:10:26 CEST] <atomnuker> planar ones have their samples spread out in each data[] plane of the avframe
[17:12:30 CEST] <DrLuke> Nice, thanks again :)
[17:13:36 CEST] <DrLuke> Oh nice, there's a format containing a vdpau surface
[17:44:29 CEST] <atbd> hi, is it possible to read an input video/audio from stdin with avformat_open_input?
[17:50:42 CEST] <klaxa> yes
[17:50:43 CEST] <klaxa> one sec
[17:51:31 CEST] <klaxa> use "pipe:0" as filename
[17:52:03 CEST] <klaxa> so: avformat_open_input(&fmt_ctx, "pipe:0", NULL, NULL);
[17:58:44 CEST] <atbd> thanks a lot !
[18:15:06 CEST] <GIFGuy> Hey there! So I'm trying to losslessly convert 2 GIFs but unsure what command do I use?
[18:15:22 CEST] <GIFGuy> They're both in the same folder, if that matters
[18:31:17 CEST] <wfbarksdale> I am writing a demuxer, and I am observing the interleaving of audio / video packets. ignorning b frames, I was wondering, is it pretty much always the case that you have some video packets beginning with a pts of x, then some audio frames beginning with a pts < x?
[18:31:46 CEST] <wfbarksdale> Is this a convention or a spec for the mp4 container
[18:35:55 CEST] <ritsuka> it depends, I think some muxers put audio before video, if the audio track comes before the video track
[18:39:03 CEST] <zerodefect> The other thing that can have an affect is the internal delay within the various encoders.
[18:57:38 CEST] <GIFGuy> Hey there! So I'm trying to losslessly convert 2 GIFs but unsure what command do I use?
[18:57:41 CEST] <GIFGuy> They're both in the same folder, if that matters
[19:02:59 CEST] <oerg866> GIFGuy: what are you trying to convert them to?
[19:09:28 CEST] <GIFGuy> oerg866: Nah I wanna keep em as GIFs as they are
[19:09:39 CEST] <GIFGuy> Like not convert,more like combine
[19:09:52 CEST] <GIFGuy> Like combine them into one file
[19:10:13 CEST] <oerg866> https://trac.ffmpeg.org/wiki/Concatenate
[19:14:07 CEST] <GifGuy2> oerg866: I looked at that page but I don't understnad
[19:14:12 CEST] <GifGuy2> It's kinda confusing
[19:16:39 CEST] <oerg866> Gifguy2: make a file in that folder called list.txt
[19:16:43 CEST] <oerg866> write this to it:
[19:16:54 CEST] <oerg866> file 'C:\whatever\file1.gif'
[19:16:55 CEST] <oerg866> file 'C:\whatever\file2.gif'
[19:16:59 CEST] <oerg866> save it
[19:17:04 CEST] <GifGuy2> done
[19:17:14 CEST] <oerg866> ffmpeg -f concat -safe 0 -i list.txt -c copy output.gif
[19:17:20 CEST] <GifGuy2> Thanks!
[19:20:11 CEST] <GifGuy2> oerg866: Gives me an error
[19:20:33 CEST] <GifGuy2> Assertion video_par->format == AV_PIX_FMT_PAL8 failed at src/libavformat/gif.c:130
[21:46:45 CEST] <oerg866> <GifGuy2> Assertion video_par->format == AV_PIX_FMT_PAL8 failed at src/libavformat/gif.c:130 <-- that's probably something a dev should look at
[21:49:14 CEST] <durandal_1707> oerg866: how to reproduce that?
[21:51:16 CEST] <oerg866> the guy asked how to join two gif files
[21:51:18 CEST] <oerg866> i said concat demuxer
[21:51:20 CEST] <oerg866> <oerg866> ffmpeg -f concat -safe 0 -i list.txt -c copy output.gif
[21:52:37 CEST] <durandal_1707> nope, use concat filter
[21:55:50 CEST] <oerg866> but concat filter re-encodes, no?
[21:55:53 CEST] <oerg866> he asked how to join
[21:55:56 CEST] <oerg866> losslesslz
[21:56:00 CEST] <oerg866> *losslessly
[21:57:25 CEST] <durandal_1707> oerg866: thing is muxer supports only basic single image gifs
[22:02:59 CEST] <oerg866> ahhhh
[22:03:01 CEST] <oerg866> okay that makes sense tehn
[22:06:35 CEST] <oerg866> hmm but now that i think about it
[22:06:41 CEST] <oerg866> gif to gif encoding should always be lossless
[22:06:48 CEST] <oerg866> since gifs have fixed limitations
[22:07:10 CEST] <oerg866> if you decimate 256 colors to 256 colors idally it should yield the same 256 colors ^^
[22:07:56 CEST] <durandal_1707> yes
[00:00:00 CEST] --- Fri May  4 2018