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

[burek]

[00:24:36 CEST] <SortaCore> sup folk
[00:24:45 CEST] <SortaCore> I need to use image2 with jpegs to make an mp4
[00:24:49 CEST] <SortaCore> in C++
[00:26:22 CEST] <DHE> you can give the image2 demuxer the same options you would the ffmpeg cli, largely using the AVDictionary for options like framerate and glob rules, and it should do most of the work on its side
[00:26:33 CEST] <DHE> have you seen the doxygen docs and the example programs?
[00:27:00 CEST] <SortaCore> nope, I have code for RTSP -> MP4, I'm just wondering what difference there would be
[00:27:08 CEST] <SortaCore> any resources would help
[00:27:33 CEST] <SortaCore> and gotchas like using variable framerate with different jpegs
[00:27:59 CEST] <SortaCore> RTSP H264 -> H264 MP4, so now it's JPEG list -> H264 MP4
[00:28:04 CEST] <DHE> well image2 assumes a constant framerate which you can set
[00:30:25 CEST] <DHE> so, I guess avformat_open_input(&avfctx, "*.jpg", av_find_input_format("image2"), NULL);    // should be largely effective if you're okay with defaults from image2
[00:30:25 CEST] <SortaCore> my current plan is to take my RTSP code, throw out the decoder, image2 for jpg seems to use mjpeg so throw that in instead, and pass each frame to the decoder
[00:31:58 CEST] <DHE> the main concern is going to be colourspace. usually H264 wants yuv420, but jpeg will produce something else that will require conversion
[00:32:39 CEST] <SortaCore> I already have X -> YUV420P/NV12 conversion between decoder and encoder
[00:32:53 CEST] <DHE> nice
[00:33:01 CEST] <SortaCore> since I had Intel QSV as one of the possible H264 encoders, and it didn't take YUV420
[00:33:27 CEST] <SortaCore> it's just what steps I have to exchange and which are no longer necessary
[00:49:46 CEST] <SortaCore> you said fixed frame rate DHE?
[00:50:04 CEST] <DHE> that's how image2 works
[00:50:14 CEST] <DHE> you're free to play around with the pts and time_base of the output streams, but that's on you
[00:50:17 CEST] <SortaCore> how much of an issue is that, something I can't work around by messing with AVPacket dts/pts timings?
[00:50:21 CEST] <DHE> and for mp4, preferably duration.
[00:50:22 CEST] <campones> hi there, any ideas why my compilation failed?  https://pastebin.com/EeDeJTVg
[00:50:37 CEST] <campones> ubuntu 16 x64 , fresh install
[15:56:09 CEST] <darkdrgn2k3> i am pulling a stream from RTMP to process with ffmpeg
[15:56:24 CEST] <darkdrgn2k3> if the RTMP stream stops/changes ffmpeg stops workign with errors "PTS .....st:0 invalid dropping"
[15:56:39 CEST] <darkdrgn2k3> is tehre anyway to prevent this or at very east have ffmpeg exit so it can be retarted
[16:23:09 CEST] <roxlu> hi, I've got two h264 video streams which seem pretty identical but one doesn't want to playback. When I use ffprobe to check fo differences I see that the one that doesn't work has [SAR] and [DAR] in the info lines. The one that does work is missing those.
[16:24:04 CEST] <roxlu> does ffmpeg extract the [SAR],[DAR] info from a nal?
[16:24:52 CEST] <JEEB> that's *one* of the places it will attempt to read the info from. then there's the container
[16:25:33 CEST] <roxlu> JEEB: thanks. when the info is stored in a nal, does it get this from the VUI? or SPS maybe?
[16:25:54 CEST] <roxlu> .. well.. I'm trying to figure out how to "remove" this info so that ffprobe shows the same info
[16:40:05 CEST] <roxlu> I was trying to remove some stuff: https://gist.github.com/roxlu/e0714c7e2792bef3061f6e084e9a866c
[16:40:11 CEST] <roxlu> but not sure why I get an error there
[16:44:43 CEST] <DHE> I think you just want "-delete_filler 1 -bsf h264_metadata"
[16:44:54 CEST] <roxlu> DHE: yeah this works, https://gist.github.com/roxlu/e0714c7e2792bef3061f6e084e9a866c#file-gistfile1-txt-L12
[16:46:17 CEST] <roxlu> but that still doesn't remove the sei, sadly :)
[16:46:27 CEST] <DHE> as for how it works, ffmpeg will do a small amount of video decoding to discover all the information about the video, including resolution and maybe SAR/DAR
[16:48:19 CEST] <roxlu> thanks, wondering why it's not in my other stream though. but I think the SEI or VUI is one of the reasons why one stream is not working correctly (not sure what though). But I'm trying to find a way to remove that nal
[16:55:52 CEST] <roxlu> what I just did:  extract .h264 from not working .mkv, convert that into .ts, then convert .ts back into a .mkv ..<-- this .mkv can be played back (?)
[16:58:57 CEST] <DHE> sounds like there's something wrong with the mkv headers then. mkv does support a lot of features like setting aspect ratios.
[17:22:16 CEST] <utack> is it to be expected that ffprobe ouputs a "pict_type="?"" for all frames in an av1 stream?
[17:23:34 CEST] <kepstin> utack: probably depends on the ffmpeg and av1 library versions. The av1 support is pretty fresh still, and probably incomplete.
[17:23:49 CEST] <utack> yeah, i guess it is normal
[17:47:35 CEST] <keglevich> I have a perfect CBR mpegts files...stream them in VLC, perfect straight bitrate line... I'd like to stream them over UDP and I'm using the following command: ffmpeg -re -i input.ts -vcodec copy -acodec copy -f mpegts "udp://239.1.1.1:5000?pkt_size=1316"
[17:48:33 CEST] <furq> keglevich: you probably need -muxrate
[17:48:38 CEST] <keglevich> the output I'm getting at udp://@239.1.1.1:5000 has lots of bitrate bursts, lots of spikes, ups and down for about +-30%...the stream isn't CBR as it should be
[17:49:18 CEST] <DHE> you'll need -muxrate set to the stream muxrate (add 10% to the basic bitrates), and add -bitrate (same number)
[17:49:20 CEST] <keglevich> what am I doing wrong? I tried all possible output combinations with bitrate, burst_bits, buffer_size, etc....nothing helps...I also tried different formats, all the same..UDP output simply isn't stable CBR
[17:49:33 CEST] <keglevich> that's also something I tried...doesn't help much
[17:50:23 CEST] <keglevich> ffmpeg -re -i input.ts -vcodec copy -acodec copy -f mpegts -muxrate 6600k "udp://239.1.1.1:5000?pkt_size=1316&bitrate=6600000" ...if that's what you had in mind?
[17:50:40 CEST] <DHE> I think so, but I've always used "-bitrate 6600k"
[17:50:51 CEST] <keglevich> minrate, maxrate, video-bitrate are 6000k
[17:51:08 CEST] <DHE> well then you're using the wrong number. add some for the audio as well
[17:51:12 CEST] <kepstin> keglevich: setting bitrate doesn't make sense when using -vcodec copy
[17:51:15 CEST] <furq> right
[17:51:17 CEST] <furq> or maxrate
[17:51:25 CEST] <DHE> kepstin: -bitrate is an option for udp:// output
[17:51:33 CEST] <keglevich> yes
[17:51:45 CEST] <keglevich> bitrate is output option
[17:51:48 CEST] <furq> doesn't that need to be in the url params though
[17:52:06 CEST] <kepstin> oh, that's supposed to be a packet pacing option for the udp output?
[17:52:15 CEST] <DHE> yes
[17:52:28 CEST] <furq> the docs don't mention that it accepts those as cli options
[17:52:36 CEST] <furq> but i've never tried it
[17:52:38 CEST] <DHE> it's relatively new. you might need ffmpeg 3.4 or newer
[17:52:57 CEST] <DHE> https://ffmpeg.org/ffmpeg-protocols.html#udp
[17:53:00 CEST] <furq> i'd probably put it in the params anyway so it's not confusing
[17:53:16 CEST] <keglevich> ffmpeg -re-i input.mp4 -c:v mpeg2video -pix_fmt yuv420p -r 25 -g 50 -b:v 5000k -c:a mp2 -ac 2 -b:a 192k -ar 48000 -minrate 5000k -maxrate 5000k -bufsize 700k -muxrate 5450k -pcr_period 30 -f mpegts "udp://239.8.1.181:5000?pkt_size=1316&bitrate=5450000"
[17:53:33 CEST] <DHE> missing a space between -re and -i
[17:53:46 CEST] <keglevich> that's the direct command I also tried...same result...I mean, same result If I make CBR .ts output first of if I do it directly to UDP
[17:53:53 CEST] <keglevich> yes ok, just a typo
[17:54:17 CEST] <keglevich> worth mentioning...CBR ts.out is perfect...it's just the issue to make UDP CBR
[17:54:31 CEST] <furq> well yeah when you restream that over udp it remuxes it
[17:54:32 CEST] <keglevich> if I play ts.out in VLC player...perfect CBR stream
[17:54:37 CEST] <furq> so you'll need to set all of the muxer options again
[17:54:48 CEST] <keglevich> if I try to "pipe" it to UDP out...no more perfect CBR, lots of spikes, and bursts
[17:54:58 CEST] <DHE> I'd use ffmpeg ... -muxrate 5800k -bitrate 5800k udp://239.8.1.181:5000?pkt_size=1316
[17:55:25 CEST] <keglevich> hmm...is this even the right syntax, shouldn't be bitrate used as udp parameter?
[17:55:36 CEST] <furq> apparently it can be either
[17:55:44 CEST] <keglevich> let my try...
[17:55:44 CEST] <DHE> like I said, this is what I've been using and I know it works. so I'm going this way
[17:55:59 CEST] <keglevich> 3 mins...I'll report back
[18:01:12 CEST] <keglevich> the result is actually the same...bitrate jumps from around 5000k to about 6200k in small bursts...long line is seen as CBR, but short intervals, lots of jumps
[18:02:41 CEST] <keglevich> https://imgur.com/Un0COq1
[18:02:53 CEST] <keglevich> that's what I get...but the line should be straight...
[18:03:33 CEST] <keglevich> worth mentioning...If i stream different formats, some jump more, some less...
[18:03:47 CEST] <keglevich> but in VLC if I play them directly...straight line
[18:04:26 CEST] <keglevich> tried all possible combinations with ffmpeg, also different ffmpeg versions...seems like that's really an issue with ffmpeg, or I'm just missing some parameters...maybe some special network adapter settings?
[18:04:35 CEST] <keglevich> I also tried on different  NIC's..same results
[18:11:04 CEST] <keglevich> strange thing is, if I look at ffmpeg cli...the output is constantly exactly 5800k (a few bits up or down) and speed 1x...so the generated stream is perfect...when that stream is piped to UDP output, the bursts appear...why?
[18:11:46 CEST] <furq> keglevich: the bitrate in the stats line is the average for the whole output
[18:11:49 CEST] <furq> it's not a rolling average
[18:11:57 CEST] <keglevich> ah ok
[18:12:26 CEST] <keglevich> but if I write the output to -f mpegts out.ts and then I play out.ts in VLC player...it's also perfect CBR stream bitrate
[18:12:42 CEST] <keglevich> the issues only appear when I try to stream it over UDP
[18:12:54 CEST] <keglevich> stream bursts are about 1mbit up/down
[18:13:05 CEST] <keglevich> as seen in graph
[18:13:28 CEST] <keglevich> I'd just like toget rid of these spikes somehow...if it's even possible
[18:34:52 CEST] <keglevich> I'd be very glad if someone still has any kind of ideas what I should try to improve the bad CBR UDP output in ffmpeg
[18:38:17 CEST] <DHE> I suspect it's caused by irregularities in the processing speed when using the -re option...
[18:39:30 CEST] <DHE> that's just a guess though
[18:40:25 CEST] <keglevich> hmm...probably not, I also tried different inputs (NDI for instance) and the result is nearly the same
[18:41:00 CEST] <keglevich> although...encoding NDI input maybe, but just maybe, produces a bit less spikes...
[18:41:45 CEST] <keglevich> strange thing is still, something I don't understand...if I use same command, and pipe output to .ts file...that file plays in VLC perfect CBR all the time
[18:41:59 CEST] <keglevich> so I guess, there's still something with UDP output
[18:43:02 CEST] <DHE> I'm suspecting it's not getting an even input rate... which is why my money is on the -re parameter
[18:43:20 CEST] <DHE> as in, udp:// isn't getting a nice big buffer to fill
[18:44:03 CEST] <keglevich> hmm...shouldn't muxrate do the job and fill the missing space with zeros so the output should be straight all the time?
[18:45:48 CEST] <DHE> maybe, but the main ffmpeg thread is sleep()'ing to maintain an input file read rate, not a consistent output rate
[18:47:25 CEST] <DHE> I'm suspecting you're seeing bursts of the output sender getting starved
[18:50:42 CEST] <keglevich> this could be possible...but why then 1mbit jumps over the max muxrate?
[18:52:06 CEST] <keglevich> if minrate=maxrate=5000k and muxrate=5800k...why then stream jumps occasionally to about 6500+k?
[18:52:56 CEST] <DHE> minrate and maxrate are options for the video encoder to contrain its bitrate. muxrate is an option for the mpegts muxer to pad the stream to that exact bitrate.
[18:53:00 CEST] <keglevich> jumps down are not that concerning anway...but I'd like to get rid at least of jups over the max allowed bitrate
[18:53:31 CEST] <DHE> I haven't checked the source, but I suspect the udp output will burst if it goes idle to make up for the lost time
[18:53:38 CEST] <keglevich> I'm sending this stream to hardware muxers, so the stream should have any too big jumps over the max allowed bandwidth
[18:54:01 CEST] <keglevich> maybe that's true
[18:54:42 CEST] <keglevich> I searched all around the net to find something documented on this topic, without any luck
[18:55:08 CEST] <DHE> if you're okay with code mods, what I'd try is adding a pre-roll to udp.c so that transmission is delayed until the buffer fills up some certain amount. like, maybe 0.3 seconds or so (so around 1/3 of the bitrate)
[18:55:22 CEST] <DHE> this is my best guess though. I'm too busy to research or try it myself right now
[18:55:40 CEST] <DHE> but I do have something similar myself using ffmpeg, but not using -re because the source is also realtime
[18:59:12 CEST] <keglevich> hmm, this seems as a big challenge for me...
[21:23:06 CEST] <roxlu> hey, when you send h264 over rtp, how do you deal with AUD, do you simply skip those?
[22:00:05 CEST] <GuiToris> Hello, I very frequently deshake my videos. In the wiki it's advised to use unsharp filter (unsharp=5:5:0.8:3:3:0.4) I thought I would read the unsharp filter's description but it's beyond my comprehension. luma matrix horizontal size and other stuffs. So what should I do, I can't figure out the right numbers because I don't know what they mean. Should I use this 5:5:0.8:3:3:0.4 or should I leave unsharp filter out?
[22:07:22 CEST] <saml> what's deshake?
[22:08:03 CEST] <saml> https://ffmpeg.org/ffmpeg-filters.html#deshake  looks like it's a thing
[22:08:41 CEST] <GuiToris> I can use deshake but I can't use unsharp filter
[22:08:52 CEST] <GuiToris> how can I get the right numbers?
[22:09:03 CEST] <saml> unsharp filter sharpens or blurs
[22:09:24 CEST] <GuiToris> I could read the description, I just don't know which numbers should I use
[22:09:39 CEST] <saml> link to the wiki you're reading?
[22:10:14 CEST] <saml> only you can try various numbers or remove unsharp filter and see if the result is good
[22:17:33 CEST] <GuiToris> that's very time consuming since I don't know what I should see
[22:17:51 CEST] <GuiToris> do you happen to know if gimp uses similar numbers?
[22:18:05 CEST] <GuiToris> I could unsharp an image there and apply it to the whole video
[22:28:57 CEST] <ChocolateArmpits> GuiToris, "luma" series of parameters influence luma, "chroma" series influences chroma
[22:29:15 CEST] <ChocolateArmpits> for each you can then set the horizontal or vertical weight
[22:29:47 CEST] <ChocolateArmpits> for example you can force the video to be sharpned more in the horizontal direction rather than vertical by making the vertical value higher
[22:30:40 CEST] <GuiToris> ChocolateArmpits, is there a number which is always good?
[22:30:51 CEST] <ChocolateArmpits> finally "amount" parameter controls what type of effect is applied, negative for bluring, positive for sharpening, and by how much each effect is added
[22:31:40 CEST] <ChocolateArmpits> well that depends on your material, generally bigger matrix size yields slower performance, not to mention the filter isn't threaded
[22:31:58 CEST] <ChocolateArmpits> it also depends on the resolution of material
[22:32:37 CEST] <ChocolateArmpits> start with the defaults and if you feel like it's not there keep increasing the amount applied
[22:33:23 CEST] <ChocolateArmpits> if the edges that get applied through sharpening are too wide, lower the matrix size parameters
[22:33:33 CEST] <ChocolateArmpits> if they aren't pronounced enough, increase their value
[22:33:53 CEST] <ChocolateArmpits> It really comes down to the resolution of material really in my experience
[22:34:36 CEST] <GuiToris> I think I should increase them. The default values arent noticable
[22:34:47 CEST] <GuiToris> thank you for your explanation, it's a lot clearer
[22:34:49 CEST] <ChocolateArmpits> so increase both size and the width
[22:34:54 CEST] <ChocolateArmpits> ehhh
[22:35:09 CEST] <ChocolateArmpits> matrix size for both horizontal and vertical and the amount
[22:35:27 CEST] <ChocolateArmpits> The default for chroma is no amount is applied, so effectively only luma gets sharpened
[22:37:02 CEST] <ChocolateArmpits> >by making the vertical value higher
[22:37:09 CEST] <ChocolateArmpits> eh meant the horizontal value
[22:38:17 CEST] <ChocolateArmpits> Also specifying each direction separately can help to equally sharpen anamorphic material, like 720x576 that gets displayed as 16:9
[22:38:24 CEST] <GuiToris> if chroma amount is 0, will chroma x 3 , y 3 look the same as chroma x 23 , y 23?
[22:38:50 CEST] <ChocolateArmpits> well yeah it should
[22:38:58 CEST] <ChocolateArmpits> as in no effect whatsoerver for chroma
[22:39:15 CEST] <ChocolateArmpits> >>a value of zero will disable the effect
[22:39:26 CEST] <ChocolateArmpits> straight from the docs
[22:39:33 CEST] <GuiToris> I don't get it why are they 5 by default if amount is 0?
[22:40:38 CEST] <ChocolateArmpits> someone probably wanted to match luma as 0 isn't an option for matrix size
[22:41:01 CEST] <ChocolateArmpits> there's nothing to be bothered about really
[22:46:39 CEST] <GuiToris> I still need a little help, I modified the original 5:5:1 ... to 8:8:1 and I got : Invalid even size for luma matrix size 8x8
[22:47:04 CEST] <GuiToris> what did I mess up?
[22:47:07 CEST] <kepstin> you have to use odd numbers
[22:47:26 CEST] <GuiToris> ahh
[22:47:29 CEST] <GuiToris> you're right
[22:47:32 CEST] <GuiToris> it's in the description
[22:47:38 CEST] <GuiToris> it escaped my attention
[22:47:39 CEST] <GuiToris> thanks
[22:49:28 CEST] <GuiToris> at last, I see something
[22:49:36 CEST] <GuiToris> thank you for your help
[22:53:26 CEST] <GuiToris> can I create only 1 image at the third second to compare them?
[22:55:45 CEST] <lays147> Hello guys.I have this command line to convert a mp4 video. https://pastebin.com/zP3yMQfv however I'm having problem in an another encoder that I have in my company, that apparently when handling i-frames, it blows up because expects i-frames between 0 and 1 and its receiving 15 and 3. I added the -keyint_min command but the command isnt working
[22:55:48 CEST] <lays147> any idea on how to solve this?
[22:59:11 CEST] <kepstin> GuiToris: sure, use "-ss 3" before the input filename to seek to 3s, and "-vframes 1" before the  output filename to write only one frame.
[23:01:35 CEST] <GuiToris> kepstin, awesome thanks
[23:04:08 CEST] <ChocolateArmpits> lays147, is the encoder actually producing a video with these parameters "-g 32 -keyint_min 15 -bf 16" ???
[23:04:52 CEST] <ChocolateArmpits> those are something I would expect an mpeg2 not to support
[23:05:07 CEST] <ChocolateArmpits> encoder*
[23:06:49 CEST] <lays147> ChocolateArmpits: sorry, the keyint argument isnt on the original command line
[23:07:02 CEST] <lays147> Was just a try that I forgot to remove on the paste
[23:07:28 CEST] <ChocolateArmpits> lays147, nevermind that, gop length should go maximum to 15, 12 is more typical
[23:07:28 CEST] <lays147> The issue is that the video from that ffmpeg, when goes to an another video rendering process, blows up.
[23:08:53 CEST] <ChocolateArmpits> not to mention b-frames only up to 3 frames
[23:09:39 CEST] <clovisw> Hi, I tried to understand a command with these parameter, -filter_complex "[0:v]scale=1920:1080[bg1];[bg1][1:v]overlay=W-w:H-h", I dont understand reading docs, what is [0:v] [bg1] and [1:v],
[23:10:09 CEST] <Mavrik> clovisw: the names in brackets are inputs outputs
[23:10:12 CEST] <ChocolateArmpits> lays147, try these: -g 12 -bf 2
[23:10:23 CEST] <ChocolateArmpits> lays147, and remove keyint_min
[23:11:03 CEST] <Mavrik> clovisw: [0:v] is video stream in first input
[23:11:08 CEST] <lays147> ChocolateArmpits: ok trying
[23:11:12 CEST] <Mavrik> clovisw: [1:v] is video stream in second input, etc.
[23:11:35 CEST] <Mavrik> clovisw: so you have several filters here - one that takes something from [0:v], scales it and then sends it to [bg1] output
[23:11:50 CEST] <Mavrik> and then another which takes video from [bg1] and [1:v] and then makes an overlay
[23:12:12 CEST] <clovisw> its a kind of watermark, but just see before, without that brackets
[23:12:20 CEST] <clovisw> I think I now understand
[23:12:22 CEST] <ChocolateArmpits> lays147, are you transcoding to xdcam spec or something?
[23:12:27 CEST] <clovisw> thanks Mavrik!
[23:12:50 CEST] <Mavrik> yeah
[23:14:12 CEST] <lays147> ChocolateArmpits: yes
[23:15:00 CEST] <ChocolateArmpits> lays147, did you look in this page ? http://www.deb-indus.org/tuto/ffmpeg-howto.htm#Encoding_XDCAM-HD-50_FCP
[23:15:52 CEST] <ChocolateArmpits> those encoding settings can make the process pretty slow
[23:16:06 CEST] <lays147> ChocolateArmpits: nope. I didnt made that command. Was another guy and now I'am fixing the mess without knowing anything about this
[23:17:13 CEST] <ChocolateArmpits> anyways first complete the previous render
[23:19:10 CEST] <lays147> ChocolateArmpits: we are using XDCAm 60Mbps
[23:19:22 CEST] <ChocolateArmpits> You mean 50mbps
[23:20:19 CEST] <ChocolateArmpits> It goes from 35Mbps for 4:2:0 video to 50Mbps for 4:2:2
[00:00:00 CEST] --- Wed Jul  4 2018