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

[burek]

[00:07:16 CET] <J_Darnley> If you aren't scaling it then it is still 720p
[00:07:54 CET] <J_Darnley> Low quality and a lack of details can make it look worse than you might want.
[00:08:28 CET] <J_Darnley> You can either spend more bits to preserve quality or spend more time encoding.
[00:30:34 CET] <harej> J_Darnley: I would be happy to do that; just not sure how if I am already setting the CRF to 0
[00:34:04 CET] <J_Darnley> Increase cpu-used perhaps
[00:34:20 CET] <J_Darnley> Otherwise find some help for libvpx
[00:34:33 CET] <J_Darnley> I don't know what options it has.
[00:37:50 CET] <harej> Wouldn't increasing cpu-used just make it go faster? Or does it refer to something else? Anyways, will check out the libvpx docs. (Now I know to check that out specifically; was fruitlessly looking at ffmpeg docs earlier.)
[00:39:55 CET] <furq> harej: http://www.webmproject.org/docs/encoder-parameters/#2-encode-quality-vs-speed
[00:40:22 CET] <harej> Thank you; will look at that after dinner
[00:40:54 CET] <TD-Linux> harej, "weird color splotches" sounds like some other problem. what player are you using?
[00:41:36 CET] <TD-Linux> also -crf 0 -b:v 7M will mean that you're basically always limited to 7Mb/s
[00:41:45 CET] <TD-Linux> also did you switch to libvpx-vp9 or not?
[00:48:33 CET] <furq> the same crf value with 10-bit x264 should be higher quality than with 8-bit, right
[00:49:23 CET] <furq> is the equivalent value just 8-bit-crf * (63/51) or is there more of an art to it than that
[00:50:57 CET] <J_Darnley> x264 adjusts internally for the bitdepth
[00:51:30 CET] <J_Darnley> I recall that crf can go negative for 8 and 10 bits
[00:52:12 CET] <J_Darnley> After the high depth was added but before the adjustment files were coming out massively larger than 8 bit.
[00:52:27 CET] <furq> i'm guessing there isn't really a fixed equivalent crf
[00:53:00 CET] <J_Darnley> crf was supposed to be The One True Quality Knob(TM)
[00:53:24 CET] <J_Darnley> it tries to be but can come up short in some cases
[00:54:13 CET] <Plorkyeran_> crf initially could go negative for 10-bit, but then it was rescaled so that 0 would be lossless
[00:54:16 CET] <J_Darnley> The recommendation was to stick with the same value when using higher depth
[00:54:19 CET] <Plorkyeran_> like with 8-bit
[00:54:24 CET] <furq> increasing by 2 for 10-bit is working pretty well anyway
[00:55:33 CET] <furq> plus it helps compensate for the reduced speed
[03:24:56 CET] <rajkosto> how do i tell the h264 decoder (using from C lib) that the packets are not annexb (it seems to be forever waiting for startcode)
[03:30:15 CET] <rajkosto> i have a=fmtp:97 profile-level-id=640020; packetization-mode=1; sprop-parameter-sets=z2qaikwrqcgc3yc1aq0bqaaa+gaadtayaaajiwaabszdu8ud44zu,ao48sa== it seems i need to dump that into extradata somehow
[03:35:40 CET] <rajkosto> ill try doing what sdp_parse_fmtp_config_h264 does
[06:30:15 CET] <adc> I'm building a small script that adds a sound at a list of specified points in a sound file - I have the basic functionality done, by looping over this command: http://pastebin.com/m6TLauek (and output). I'm running into an issue with the placement of the sound, with a slight drift per sound; after adding a few hundred (or thousand) sounds to the file it's drifted by close to a full second or more, which makes the output unusable.
[06:30:27 CET] <adc> Is there any way to make ffmpeg more precise in terms of sound placement?
[08:32:58 CET] <durandal_170> adc: delay is in double, so use decimal
[08:33:32 CET] <adc> Can you give me an example of format?
[08:34:22 CET] <adc> Not sure what you mean by "decimal". What unit is 1? Seconds?
[08:35:59 CET] <durandal_170> 1000 of second
[08:37:02 CET] <adc> Documentation claims my use is correct (for a delay of 250 milliseconds). Could you give me an example?
[19:56:05 CET] <rajkosto> i must be doing somethign wrong with this decode
[19:56:28 CET] <rajkosto> it says every frame has all the MV errors in ? type frame
[19:56:38 CET] <rajkosto> and it uses a LOT of cpu to decode
[19:57:45 CET] <rajkosto> (so much that it can barely keep up with 720p30 on this monster machine (granted it is using only one core)
[20:00:58 CET] <jkqxz> Your decode must be mostly right to get that far.
[20:01:54 CET] <jkqxz> Where is the stream coming from?  Could it be corrupted somehow (having gone over an unreliable channel), or otherwise somehow incomplete (truncated, say)?
[20:05:44 CET] <malenki> hi
[20:06:15 CET] <malenki> why can ffprobe tell me the bitrate of an opus audio file bot not the bitrate of an opus audio stream of a video?
[20:06:40 CET] <DHE> when there's just 1 stream it's easier to measure than when there's 2
[20:06:59 CET] <malenki> or better: how can i know the bitrate of an opus audio stream inside a video?
[20:07:45 CET] <BtbN> extract the whole stream, divide size by runtime
[20:14:42 CET] <rajkosto> jkqxz, it was because i compiled my own ffmpeg with toolchain=msvc
[20:14:49 CET] <rajkosto> (so i could have pdbs and stuff while developing)
[20:15:05 CET] <rajkosto> using zeranoe dlls cpu usage is normal and no errors
[20:15:59 CET] <BtbN> so you built without yasm or something like that?
[20:16:04 CET] <rajkosto> nope it used yasm
[20:16:07 CET] <rajkosto> i saw it during make
[20:17:57 CET] <rajkosto> i assume the cpu usage was because it thought all the MVs had errors so was trying to conceal
[20:41:22 CET] <rajkosto> jkqxz, now i tried a stream that uses intra refresh, and it took like a full minute or so for it to give me a frame
[20:41:52 CET] <rajkosto> is there something i need to pass for it to recognize intra refresh sequence points ?
[20:42:23 CET] <JEEB> you must have a really long refresh period
[20:42:38 CET] <rajkosto> i dont know how to set it
[20:42:41 CET] <rajkosto> i did keyint=3
[20:42:43 CET] <rajkosto> 30
[20:45:05 CET] <rajkosto> is there a way to set it so i get garbled mess anyway? instead of waiting for something
[20:45:33 CET] <JEEB> there's IIRC a parameter that would output broken pictures, yes
[20:45:46 CET] <JEEB> "Disables IDR-frames, instead x264 uses intra coding for each macroblock in the frame every --keyint frames. Blocks are refreshed in a horizontally scrolling column - the 'refresh wave'. This benefits low-latency streaming by making it possible to achieve more constant frame sizes than is possible with standard IDR-frames. It also increases the resilience of the video stream to packet loss. This option does r
[20:45:52 CET] <JEEB> educe compression efficiency, hence only use it when needed."
[20:46:03 CET] <JEEB> hmm, not sure how to read that
[20:46:18 CET] <rajkosto> it should output a SEI that says how many frames after it you need to decode to get a full frame
[20:46:27 CET] <JEEB> umm
[20:47:39 CET] <jkqxz> Is the source a whole stream beginning with an IDR frame, or is the point here that you are turning up randomly in the middle of the stream and then waiting until a whole picture is present that you can decode?
[20:47:47 CET] <rajkosto> its a rtp stream
[20:47:51 CET] <rajkosto> so random in the middle
[20:48:06 CET] <rajkosto> with non intra refresh its about a second or two, consistent with my keyint
[20:48:11 CET] <rajkosto> with intra refresh its forever
[20:48:19 CET] <jkqxz> From multicast or whatever, so you can't send an RTCP intra refresh request?
[20:48:30 CET] <rajkosto> yes its onetomany
[20:48:49 CET] <JEEB> trying to see how exactly intra refresh works with x264
[20:49:00 CET] <JEEB> http://git.videolan.org/?p=x264.git;a=commit;h=cde39046222b112261179144033e7a51430783d0 is the commit that added it
[20:49:50 CET] <JEEB> so in theory if you have keyint=30 then it should refresh in 30 pictures if I understand correctly
[20:49:56 CET] <JEEB> and after that you should have correct image
[20:50:59 CET] <rajkosto> also, if i have the SPS,PPS, and stuff in extradata of AvCodecContext i shouldnt have to use the mp4toannexb filter, right ?
[20:51:30 CET] <JEEB> mp4toannexb filter is only required if you need to convert from that type to another type
[20:51:40 CET] <JEEB> I mean, AVCc to Annex B
[20:51:55 CET] <jkqxz> RTP streams are just NAL units, once you've reassembled the fragmentation units and whatnot.  You need to add the start code, but nothing else.
[20:52:21 CET] <rajkosto> rtp is headerless, so i add length header because my extradata is avcc format
[20:53:51 CET] <rajkosto> nvm, it seems it all works
[20:54:01 CET] <JEEB> ok, so the sei recovery point just contains your "h->param.i_keyint_max = X264_MIN( h->param.i_keyint_max, (h->param.i_width+15)/16 - 1 );"
[20:54:29 CET] <JEEB> which should be 30 pictures if your keyint is set correctly
[20:54:54 CET] <rajkosto> yeah its fine i bungled something
[21:23:02 CET] <adc> I'm building a small script that adds a sound at a list of specified points in a sound file - I have the basic functionality done, by looping over this command: http://pastebin.com/m6TLauek. I'm running into an issue with the placement of the sound, with each sound drifting a bit; after adding a few hundred (or thousand) sounds to the file it's drifted by close to a full second or more, which makes the output unusable. Is there any way t
[21:25:26 CET] <adc> Also, would there be any faster way to do what I want to do? As it is it takes over an hour for a 50~ minute long file because it has to decode and re-encode each time it adds a sound, but I can't figure out a way to add the same sound multiple times in one pass.
[21:30:23 CET] <J_Darnley> Render your additions into one continuous audio stream and then mix that once?
[21:31:39 CET] <adc> I can't figure out how to do that - as far as I can tell, it's not possible to use the same input twice in one statement?
[21:32:25 CET] <J_Darnley> There's the split filter(s)
[21:32:44 CET] <J_Darnley> but I probably wouldn't do that with ffmpeg anyway.
[21:33:17 CET] <adc> I'm open to suggestions
[21:34:03 CET] <J_Darnley> Well I don't know what exactly what you're doing
[21:34:28 CET] <J_Darnley> For a few "randomly" placed sounds I would probably use audacity
[21:34:40 CET] <adc> I'm adding game sounds to a TAS I built
[21:35:08 CET] <adc> Doing it manually isn't really an option, since there are thousands of individual sounds to add
[21:35:09 CET] <J_Darnley> For many regularly occuring sounds I would have a script conat sounds and silence as I needed.
[21:35:30 CET] <J_Darnley> How do you know when they occur?
[21:36:06 CET] <adc> I had the game output a time-since-game-start (in milliseconds) each time a sound played.
[21:36:17 CET] <J_Darnley> ah
[21:37:20 CET] <J_Darnley> asplit won't help you much there either.
[21:37:39 CET] <J_Darnley> You would be "splitting" thousands of times.
[21:38:41 CET] <J_Darnley> I would either cobble something outside ffmpeg or write a really ugly filter to do it inside ffmpeg.
[21:39:36 CET] <adc> Like I said, I'm open to suggestions but I couldn't find any other way to do it while searching for a solution
[21:41:02 CET] <J_Darnley> Sorry, I don't have anything better than that.
[21:41:29 CET] <J_Darnley> Although you could see if sox has a better way of adding those sounds.
[21:41:42 CET] <adc> I do have the ffmpeg part working, it's just not accurate enough
[21:42:06 CET] <J_Darnley> I thought you were also complaining about speed.
[21:42:25 CET] <adc> Yeah, it's annoying but if I can get an accurate output I can survive with it
[21:45:39 CET] <adc> A couple hours of processing is so much better than 30 hours of manual work, so.
[23:54:15 CET] <qwertzsqwert> From the docs the following does not work for me: ffmpeg -f jack -i  ffmpeg -y out.wav
[23:54:59 CET] <durandal_170> error?
[23:55:00 CET] <qwertzsqwert> Any ideas?
[23:55:32 CET] <qwertzsqwert> Sure: unknown input format
[23:56:01 CET] <JEEB> have you built with jack?
[23:56:31 CET] <durandal_170> than ffmpeg is not compiled with it
[23:56:47 CET] <qwertzsqwert> What is the build prefix?
[23:57:28 CET] <qwertzsqwert> ^switch
[23:58:58 CET] <JEEB> ./configure --help | grep 'jack'
[00:00:00 CET] --- Sun Feb 21 2016