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

[burek]

[00:03:40 CEST] <wiak> stupid question, when i compile ffmpeg with ./configure it will decode most formats/codecs?
[00:09:05 CEST] <podman> furq: maybe i'll just get a dell poweredge r930
[00:09:32 CEST] <podman> 72 cores!
[00:09:37 CEST] <kepstin> wiak: the default will be to enable pretty much all the built-in decoders, which should give you decent coverage of almost everything.
[00:10:17 CEST] <kepstin> (encoders is a different matter; many formats require external encoder libraries, which have to be enabled explicitly)
[01:58:49 CEST] <varu-> i ended up using socat to just create duplicates of the ts stream, then processing each with a ffmpeg instance
[01:59:03 CEST] <varu-> allows me to modify each stream individually should i choose to, without taking the others down
[01:59:11 CEST] <varu-> not the most efficient, but it works
[02:18:00 CEST] <DHE> that would work...
[04:47:42 CEST] <circ-user-HK0l0> how to set ffmpeg parameter to make it keep a
[04:47:53 CEST] <circ-user-HK0l0> persistent connection on hls
[04:50:21 CEST] <circ-user-HK0l0> i have try set multiple_requests and http header Connection=keep-alive;but doesn't work :(
[07:08:25 CEST] <petecouture> anyone ever get encoding hickups coming from a live rtp going to .ts segments? Like if the bandwidth of the live stream drops and comes back the encoder stalls for 10 segments then processes a ton of data then stalls for 10 segments?
[07:13:45 CEST] <momomo> petecouture, i dont
[07:14:07 CEST] <momomo> but i am not sure i have experienced such lagging
[07:15:49 CEST] <petecouture> I have some data
[07:16:08 CEST] <petecouture> In the form of progress and file generation.
[07:16:41 CEST] <petecouture> http://pastebin.com/ph3QSW7e
[07:17:44 CEST] <petecouture> The first part is the command used. The second is the progress outputted from ffmpeg and the third is the traced out directory. See how the files are good for the first 10 segments then they are empty. It start because of an initial drop in bandwidth but when bandwidth comes back it doesn't recover.
[07:28:02 CEST] <barryp123> Any fluent-ffmpeg users in the house?
[07:28:15 CEST] <petecouture> Yup
[07:28:27 CEST] <petecouture> been using for about 3 weeks now though
[07:29:26 CEST] <barryp123> Trying to use takeScreenshots to get 100 screenshots of a video. Works great when I specify timemarks, but without timemarks, and specifiying count, it falls apart
[07:30:23 CEST] <petecouture> barryp123: dunno sorry mate.
[07:30:28 CEST] <petecouture> doing rtp to hls
[07:31:00 CEST] <barryp123> basically, it errors out unless i use timemarks
[07:31:07 CEST] <barryp123> ahh nice!
[07:31:22 CEST] <petecouture> no royal pain
[07:31:41 CEST] <barryp123> hahah everything that is worth it, is always a pain
[07:31:44 CEST] <petecouture> like a satalite encoding system
[07:31:48 CEST] <petecouture> true
[07:32:48 CEST] <petecouture> I'm actually switching gears. This system is actually webrtc -> rtp -> ffmpeg -> hls. But if I can't fix this bandwdith drop I'm just going to build out a client side application do the ffmpeg encoding.
[07:32:49 CEST] <barryp123> sounds cool!! Im not there yet& through getting screencaps would be pretty trivial.. tempted to push 100 values to the timemarks array
[07:33:04 CEST] <petecouture> Will help offload the encoding cost as well.
[07:36:35 CEST] <parrot> is MFXClose() part of ffmpeg or is it part of Intel MediaSDK?
[08:11:14 CEST] <momomo> what language do you use for ffmpeg scale ?
[08:12:04 CEST] <momomo> i am thinking about floor, min gt functions .. is tehre a reference for these ?
[08:13:32 CEST] <momomo> I am getting an error for this scale function: http://hastebin.com/onusazecax.mel
[08:13:40 CEST] <momomo> but only if height is too low
[08:13:47 CEST] <momomo> at 300 i get an error
[08:14:10 CEST] <momomo> for width 50 is ok ... but for height less than 300 i am getting:
[08:14:10 CEST] <momomo> 3220225315 : Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
[08:14:28 CEST] <momomo> i don't get it .. becasue the min(1, ... ) should return the lowest value .. so what could be wrong
[08:18:17 CEST] <momomo> basically height will be: min(1,min(400/iw,300/ih))*ih
[08:19:29 CEST] <momomo> is there a way to log the result of this calculation?
[08:25:20 CEST] <momomo> I see this error: [libx264 @ 0x17de8e0] width not divisible by 2 (375x300) but it is strange
[08:28:16 CEST] <momomo> actually, just using: "scale=375:300" will cause an error so it is not my scale function
[08:28:25 CEST] <momomo> the error: [libx264 @ 0x12c1da0] width not divisible by 2 (375x300)
[08:28:40 CEST] <momomo> so wierd
[08:30:57 CEST] <momomo> seems to be possible error in libx264 ?
[09:30:04 CEST] <Abatap> Hey guys! Anyone knows what's the deal with ffmpeg constantly receiving HTTP 403 when feeding it a periscope.tv m3u8 link. ffplay works just fine btw.
[10:20:18 CEST] <thebombzen> momomo: it's not an error in libx264. The H.264 standard requires the width and height to be divisible by two.
[10:20:38 CEST] <thebombzen> it should be anyway tho because of 4:2:0 chrome subsampling.
[10:21:03 CEST] <momomo> thebombzen, so certain values lead to errror .. i am calculating the with and height using iw and ih
[10:21:28 CEST] <thebombzen> there's no easy way to check to see if the input is odd and if it is add 1. I mean you could do that but it'd be complicated.
[10:21:33 CEST] <momomo> so in this case width 375 is causing an issue
[10:21:56 CEST] <thebombzen> Instead, I recommend calculating the output width/height using bash, and then substituting it in
[10:22:23 CEST] <momomo> hmm .. isn't there a modulo function perhaps for scale ?
[10:22:25 CEST] <momomo> what language is that?
[10:22:41 CEST] <momomo> min floor functions are available
[10:22:54 CEST] <thebombzen> there is. but you'd have to substitute that entire expression into it. not worth it.
[10:22:56 CEST] <thebombzen> check this out: https://www.shell-tips.com/2010/06/14/performing-math-calculation-in-bash/
[10:23:38 CEST] <thebombzen> I'd use a bash script to do the actual calculating, assume you're executing ffmpeg from a bash script. If you're executing ffmpeg from a language like C, then do the math in C.
[10:24:01 CEST] <momomo> thebombzen, the thing is that I am not using bash .. plus ffmpeg needs these values before the command is issued .. are you suggesting i do a request first get the width and height of the srouce and then reconnect ?
[10:24:46 CEST] <momomo> i do not know the  width and height of the source . ffmpeg knows this and places it in ih and iw
[10:25:03 CEST] <momomo> so bash, C or java is too early
[10:25:18 CEST] <momomo> i think substition is ok for me now
[10:25:30 CEST] <momomo> but I can
[10:25:40 CEST] <momomo> t find a reeference for finding these functions
[10:25:45 CEST] <momomo> is this c functions ?
[10:25:57 CEST] <thebombzen> another thing you could do is use something like scale="trunc(3/2*iw/hsub)*hsub:trunc(3/2*ih/vsub)*vsub"
[10:26:32 CEST] <thebombzen> trunc truncates an integer. so you could divide it by two, truncate it, then multiply it by 2.
[10:26:41 CEST] <thebombzen> that would ensure it's always even
[10:26:46 CEST] <momomo> good trick
[10:26:53 CEST] <thebombzen> (it's in the documentation)
[10:27:15 CEST] <thebombzen> (I suggest you read https://ffmpeg.org/ffmpeg-filters.html#scale-1) in its entirity
[10:27:21 CEST] <momomo> this is the command i am using: http://hastebin.com/onusazecax.mel
[10:27:30 CEST] <momomo> it chooses either max height or max width
[10:27:49 CEST] <momomo> so I will try to trunc it now
[10:28:11 CEST] <thebombzen> in particular, read this line
[10:28:20 CEST] <thebombzen> "If one of the values is -n with n > 1, the scale filter will also use a value that maintains the aspect ratio of the input image, calculated from the other specified dimension. After that it will, however, make sure that the calculated dimension is divisible by n and adjust the value if necessary."
[10:28:54 CEST] <thebombzen> so if you set the width to whatever you are trying to scale, and the height to -2, in scales the height by the same scale factor as the width, and then ensures both are divisible by 2.
[10:30:10 CEST] <momomo> so : scale=min(1\,min(400/iw\,300/ih))*iw:-2
[10:30:13 CEST] <momomo> should do the trick
[10:30:29 CEST] <thebombzen> also
[10:30:32 CEST] <thebombzen> you should consider force_original_aspect_ratio
[10:30:40 CEST] <thebombzen> there's a reason the documentation exists
[10:30:50 CEST] <thebombzen> because there's all these amazing features that you won't know about until you read up
[10:30:52 CEST] <momomo> it's a big documenation
[10:31:05 CEST] <thebombzen> which is why you read exactly the -vf scale documentation
[10:31:10 CEST] <thebombzen> and not all the other filters
[10:31:31 CEST] <momomo> i did
[10:31:48 CEST] <thebombzen> did you try force_original_aspect_ratio?
[10:31:50 CEST] <momomo> but I am calculating the scale .. i am not sure how this argument would help
[10:31:59 CEST] <momomo> for instance i might get
[10:32:02 CEST] <momomo> 375:-2
[10:32:19 CEST] <thebombzen> so it appears you're trying to scale it down in a way where it will fit inside a 400x300 frame, right?
[10:32:20 CEST] <momomo> your first statement would ensure it is divisible by two
[10:32:31 CEST] <momomo> yes.. not bigger either wway
[10:32:34 CEST] <thebombzen> okay
[10:32:36 CEST] <momomo> can not go outside
[10:33:49 CEST] <thebombzen> did you try -vf scale=force_original_aspect_ratio=decrease:s=400x300
[10:33:55 CEST] <thebombzen> cause that does what you're trying to do
[10:34:02 CEST] <thebombzen> and it explains it in the documentation
[10:36:36 CEST] <momomo> one moment
[10:38:37 CEST] <momomo> -vf scale=force_original_aspect_ratio=decrease:s=1024x300 caused an error
[10:38:50 CEST] <momomo> but the first one with -2 worked
[10:38:53 CEST] <momomo> i think
[10:38:56 CEST] <momomo> let me retry
[10:39:38 CEST] <momomo> no, also flunked
[10:39:40 CEST] <momomo> with 300
[10:39:52 CEST] <momomo> i am going to try trunc
[10:43:25 CEST] <momomo> now I get 374x300
[10:43:38 CEST] <momomo> for scale=trunc(iw*min(1\,min(1024/iw\,300/ih))/2)*2:-2
[10:46:45 CEST] <momomo> the problem now is though that the aspect ratio gets a bit flawed
[10:46:51 CEST] <momomo> i had 1.25 originall
[10:46:52 CEST] <momomo> y
[10:46:56 CEST] <momomo> now it's 1.253333
[10:47:39 CEST] <momomo> ideally you'd want to go inside the box until you hit the aspect ratio perfectly
[10:49:40 CEST] <rrva> How can I access the POC of a h264 video packet after having decoded it with av_read_frame ?
[10:49:59 CEST] <momomo> thebombzen, it appears to me as if -vf scale=force_original_aspect_ratio=decrease:s=400x300 is broken
[10:50:08 CEST] <momomo> as it is not safe
[10:52:06 CEST] <thebombzen> momomo: are you using the latest ffmpeg?
[10:52:10 CEST] <thebombzen> git master?
[10:52:35 CEST] <thebombzen> also in general you should post your complete, uncut command and output to a paste website before asking for help
[10:53:15 CEST] <momomo> no, it's some ubuntu version
[10:56:12 CEST] <momomo> thebombzen, the command http://hastebin.com/hacimegiko.md
[10:56:40 CEST] <thebombzen> first of all
[10:56:50 CEST] <momomo> thebombzen, Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
[10:56:55 CEST] <thebombzen> url.com is fake. which means you edited the line. don't do that
[10:56:59 CEST] <thebombzen> second of all... and the output?
[10:57:16 CEST] <thebombzen> third of all, you should use the latest git master
[10:57:55 CEST] <momomo> thebombzen, http://hastebin.com/ahiqekecof.pas
[10:58:12 CEST] <momomo> thebombzen, i will look into that and how to build ffmpeg manually
[10:58:33 CEST] <momomo> thebombzen, the reason i did that is to hide what is unprotected server
[10:58:34 CEST] <thebombzen> 1. that's an old version.
[10:58:57 CEST] <thebombzen> 2. -framerate is an input option. you don't need it.
[10:59:07 CEST] <thebombzen> 3. don't use libvo_aacenc
[10:59:24 CEST] <thebombzen> it's awful awful awful. if you want a free encoder, use the built-in one. it's actually stable nowadays
[11:00:59 CEST] <momomo> ook, do I specify some other option?
[11:01:08 CEST] <momomo> or just ignore it ?
[11:01:34 CEST] <thebombzen> don't use -r and -framerate. -framerate is used for specifying the framerate of input video
[11:01:40 CEST] <momomo> ook
[11:01:49 CEST] <momomo> i think -r is needed for keysize and g
[11:02:05 CEST] <momomo> someone told me they need to be 5 multiple of -r
[11:02:06 CEST] <thebombzen> you should try to avoid x264 options and just pick a preset
[11:02:16 CEST] <thebombzen> x264's presets are good
[11:02:22 CEST] <momomo> the option i have is crf 23
[11:02:43 CEST] <furq> if you're using libvo-aacenc then you're not using a recent enough ffmpeg build to have the worthwhile builtin encoder
[11:02:45 CEST] <momomo> the other ones are neccessary for hls to cut at a fixed time
[11:02:48 CEST] <momomo> i believe
[11:02:56 CEST] <furq> and yeah you need -g and -keyint_min for hls
[11:03:18 CEST] <momomo> do i need -x264-params scenecut=0
[11:03:22 CEST] <furq> no
[11:03:22 CEST] <momomo> i am not sure what it does
[11:03:26 CEST] <furq> keyint_min will do the same thing
[11:03:50 CEST] <furq> or rather, having keyint_min and g be the same value will disable scenecut anyway
[11:03:57 CEST] <thebombzen> x264 has a feature called "scenecut detection" where it won't encode an inter-frame if it detects a scenecut and will reencode it as intra-only
[11:04:09 CEST] <thebombzen> it's simply the encoder being intelligent and isn't a feature of the bitstream
[11:04:18 CEST] <thebombzen> you shouldn't turn it off
[11:04:29 CEST] <furq> it makes no difference if you have fixed GOP size
[11:04:40 CEST] <momomo> so the values of scenecut seems to do what I am after with -r -g and min
[11:04:56 CEST] <momomo> or maybe not
[11:05:04 CEST] <furq> also you don't need to care about preserving the aspect ratio because it's anamorphic
[11:05:08 CEST] <furq> it'll scale to the correct DAR regardless
[11:05:17 CEST] <furq> in the player, that is
[11:05:42 CEST] <thebombzen> welp, it appears that someone more knowledgeable than me has arrived. time to peace out
[11:07:10 CEST] <furq> also i'm pretty sure that -threads 2 is only applying to the first output file
[11:08:09 CEST] <momomo> ook good to know
[11:08:53 CEST] <momomo> but there is a bug using -vf scale=force_original_aspect_ratio=decrease:s=1024x300
[11:09:05 CEST] <furq> for the record i think someone suggested scenecut=0 because you can use that instead of keyint_min
[11:09:10 CEST] <momomo> so I ended up having to calculate 374:-2
[11:09:32 CEST] <furq> i've not used the scale filter intensively enough to know if that's a bug
[11:09:59 CEST] <momomo> furq, it is a bug because the program will fail
[11:10:03 CEST] <momomo> and shut down
[11:10:14 CEST] <momomo> if values are not perfect and divisible by two
[11:10:57 CEST] <furq> that's not a bug, h.264 needs mod2 width
[11:11:06 CEST] <furq> and yuv420p needs mod2 height
[11:11:16 CEST] <furq> there's nothing that can be done about that
[11:12:22 CEST] <momomo> but it makes it pretty unreliable since you can not easily know what source format is .. and you could end up with odd numbers
[11:12:36 CEST] <momomo> this works: scale=trunc(iw*min(1\,min(375/iw\,300/ih))/2)*2:-2
[11:12:55 CEST] <momomo> but produces: 374x300
[11:13:00 CEST] <momomo> which is not 1.25
[11:13:12 CEST] <momomo> aspect ratio a little lost
[11:13:19 CEST] <momomo> but maybe that is insignificant ?
[11:13:31 CEST] <momomo> furq, your email seems broken
[11:13:54 CEST] <furq> it doesn't really matter if it's 1.25, you're setting the SAR anyway
[11:13:59 CEST] <furq> and yeah i know ;_;
[11:14:31 CEST] <furq> i need to go yell at my domain registrar
[11:14:43 CEST] <momomo> it must be godaddy because they suck
[11:15:43 CEST] <momomo> scale=force_original_aspect_ratio=...:s=1024x300 should have an option fitapspect
[11:16:09 CEST] <momomo> which will decrease the size of both height and width until both are whole integers
[11:16:17 CEST] <momomo> while maintaining aspect
[11:16:37 CEST] <momomo> it might be a bit tricky to find such numbers, but there are probably algoritms
[11:17:55 CEST] <furq> it is odd that there isn't some way to get force_original_aspect_ratio to scale to mod2
[11:18:04 CEST] <furq> unless i'm missing something
[11:19:59 CEST] <momomo> even scale will fail for odd numbers
[11:20:03 CEST] <momomo> scale=trunc(iw*min(1\,min(375/iw\,300/ih))/2)*2:-2 but this works
[11:20:10 CEST] <momomo> but i would like to round perhaps
[11:20:19 CEST] <momomo> is there a round method ?
[11:20:23 CEST] <momomo> rather than trunc
[11:20:33 CEST] <momomo> or that might fail
[11:20:42 CEST] <momomo> with / 2 * 2
[11:21:08 CEST] <momomo> no that should work
[11:21:27 CEST] <furq> https://ffmpeg.org/ffmpeg-utils.html#Expression-Evaluation
[11:21:50 CEST] <furq> there's floor and ceil but no round
[11:22:31 CEST] <furq> maybe floor(x+0.5) will work
[11:23:38 CEST] <momomo> floor and trunc is the same right?
[11:23:50 CEST] <furq> for positive values, yes
[11:25:19 CEST] <momomo> 3220225315 : [NULL @ 0x14de980] Unable to find a suitable output format for '+'
[11:25:28 CEST] <momomo> for scale=floor(iw*min(1\,min(1024/iw\,768/ih))/2 + 0.5)*2:-2
[11:25:31 CEST] <momomo> or wait
[11:25:38 CEST] <furq> quote it or get rid of the spaces
[11:25:50 CEST] <momomo> scale=floor(iw*min(1\,min(1024/iw\,768/ih))/2+0.5)*2:-2 worked
[11:27:16 CEST] <furq> also if you're on *nix you can use the static builds if you want the up-to-date aac encoder
[11:27:20 CEST] <furq> http://johnvansickle.com/ffmpeg/
[11:28:19 CEST] <momomo> ooh nice
[11:28:23 CEST] <momomo> i ended up using scale=floor(iw*min(1\,min(1024/iw\,300/ih))/2+0.4999999)*2:-2
[11:28:34 CEST] <momomo> to prefer rounding down if they are equal
[11:58:05 CEST] <kenny__> Hello, -t (or -to) param should quit/kill ffmpeg with -map 0 param? If i use without -map, ffmpeg will quit, but if i use -map 0, ffmpeg only stops saving to file but still lunched - its normal?
[12:14:02 CEST] <momomo> pkill ffmpeg :p
[12:41:44 CEST] <kenny__> momomo: i can`t, i have more than one ffmpeg process, other must still running; i can base by PID but this is not the solution ;)
[12:42:02 CEST] <momomo> it works fine to kill ffmpeg for me
[12:43:25 CEST] <kenny__> "it" mean pkill or with -t param?
[15:28:08 CEST] <iticus> hello! I'm trying to re-stream a stream using RTMP but I'm getting an error regarding not being able to connect to the "output"
[15:28:32 CEST] <iticus> ffmpeg -re -i input_stream -c copy -f flv rtmp://localhost:10000/live
[15:29:04 CEST] <iticus> I'm getting: Connection to tcp://localhost:10000 failed: Connection refused; but shouldn't ffmpeg listen on port 10000 rather than trying to connect to it?
[15:29:58 CEST] <furq> no?
[15:30:08 CEST] <furq> ffmpeg isn't an rtmp server
[15:34:17 CEST] <iticus> furq, what are my options in this case?
[15:35:10 CEST] <iticus> I tried to follow some examples from: https://www.wowza.com/forums/content.php?213-How-to-use-FFmpeg-with-Wowza-Media-Server-(MPEG-TS)
[15:41:55 CEST] <iticus> what other options do I have to re-stream the content so that I could play the stream using something like VLC for example?
[15:45:31 CEST] <furq> if you want an rtmp server then https://github.com/arut/nginx-rtmp-module
[15:46:41 CEST] <furq> but if you were only listening on localhost then why not just play the stream with vlc/mpv
[15:54:49 CEST] <iticus> furq, mpv can play the stream directly but VLC cannot; that is why I tried to re-stream it
[15:55:26 CEST] <iticus> I found out that  -f mpegts udp://127.0.0.1:10000 will stream it and "vlc udp://@:10000" will play it OK
[15:56:56 CEST] <DHE> that would work for real-time live streams
[17:34:58 CEST] <Amitari> Does anyone know how to cut the audio from a video from a certain frame, to a certain frame, and have it saved as FLAC?
[17:37:07 CEST] <Amitari> I would normally do this in Audacity, but the video has a weird framerate with a bunch of decimals, so I can't really do it.
[17:43:14 CEST] <courrier> Amitari: somehting like ffmpeg -i in.mp4 -ss 00:01:00 -t 10 -vn -acodec flac out.flac ?
[17:43:46 CEST] <courrier> (extracts t=10 seconds from the ss=1st minute)
[17:43:46 CEST] <Amitari> Yeah, but I don't really think I can input it in time because of the odd framerate, the time has a whole bunch of decimals.
[17:44:28 CEST] <kepstin> Amitari: the seek values in ffmpeg can have a bunch of decimal places to specify precision, it's not hard to be frame-accurate
[17:45:13 CEST] <Amitari> In seconds, it's from "722.240454888" to "730.815517112".
[17:45:28 CEST] <Amitari> I just divided the frame numbers by the frame rate
[17:45:36 CEST] <Amitari> I just don't know how this works.
[17:45:40 CEST] <Amitari> Too many decimals.
[17:46:04 CEST] <scoofy> it's likely a floating point approximation of a rational number
[17:46:14 CEST] <kepstin> well, the frame rate itself doesn't have any decimals, it's almost certainly a fraction like 24000/1001
[17:46:41 CEST] <kepstin> (ntsc video has this annoying /1001 thing because of a quirk of how they added color to the signal)
[17:46:46 CEST] <Amitari> The frame rate is "29.970628". :P
[17:46:57 CEST] <kepstin> ok, that's exactly 30000/1001 :)
[17:47:12 CEST] <Amitari> wat
[17:49:10 CEST] <kepstin> but yeah, there's no real good way in ffmpeg to trim an audio/video stream in ffmpeg using video frame counts
[17:49:37 CEST] <kepstin> you can't "seek" to a video frame, only to a time, so the -ss option can't do it - you actually have to decode the video and count frames to know where to start :/
[17:50:29 CEST] <kepstin> one thing you could try is to use the 'ffprobe -show_frames' output to figure out the exact time of the frames you're looking at.
[17:51:06 CEST] <Amitari> Should I type "ffprobe -show_frames 21646 21903" then?
[17:53:17 CEST] <kepstin> no, 'ffprobe -show_frames video.mkv' - it'll print a chunk of data for each frame including the exact timestamps. Might be hard to fine frames by count in the output, tho.
[17:54:23 CEST] <kepstin> if the video is constant fps, tho, just doing "frameno * 1001 / 30000" should do.
[17:55:45 CEST] <Amitari> Lemme try.
[17:56:58 CEST] <Amitari> [NULL @ 0x557c5b9d4340] Unable to find a suitable output format for 'frameno'
[17:56:58 CEST] <Amitari> frameno: Invalid argument
[17:57:39 CEST] <sb_> [Is there a && Is this the] channel for people using libav or is the libav-users list the best place to go?
[17:58:34 CEST] <kepstin> Amitari: ... you type that into your calculator, replacing 'frameno' with the number of the frame
[17:58:50 CEST] <kepstin> Amitari: it gives you the exact time to use in seconds for the -ss
[17:59:17 CEST] <kepstin> sb_: well, if you stay here we can help you switch to ffmpeg instead of libav :)
[17:59:38 CEST] <Amitari> Alright, lemme try this then.
[17:59:49 CEST] <furq> i'm guessing he's on one of the unfortunate debian/ubuntu releases which switched to libav
[18:00:08 CEST] <Amitari> That was one of the reasons I switched to Arch.
[18:00:20 CEST] <furq> debian is back on ffmpeg now
[18:00:20 CEST] <sb_> kepstin: sorry, not the fun little chair switch we all did a few years ago.. I mean writing code against libavformat, libavcodec, etc
[18:00:30 CEST] <furq> oh right
[18:00:35 CEST] <furq> no this is the channel for that
[18:00:48 CEST] <furq> or the ffmpeg-user list
[18:01:08 CEST] <Amitari> Where in the command do I write where it should end?
[18:01:09 CEST] <kepstin> sb_: that said, a lot of the stuff on this channel is helping people with the ffmpeg command-line tool, there's fewer people here with api experience :/
[18:01:22 CEST] <Amitari> I'm using the "ffmpeg -i in.mp4 -ss 00:01:00 -t 10 -vn -acodec flac out.flac" thing.
[18:01:31 CEST] <furq> Amitari: -t is where it ends
[18:01:36 CEST] <Amitari> Oh, alright.
[18:01:40 CEST] <furq> 10 seconds after -ss
[18:01:49 CEST] <Amitari> wat
[18:01:58 CEST] <Amitari> Should I write the end time where 10 is?
[18:01:59 CEST] <kepstin> Amitari: -t sets the duration of the clip to be output.
[18:02:07 CEST] <sb_> kepstin furq thanks, I'll give it a go then
[18:02:15 CEST] <furq> if you want the end time then use -to 00:01:10
[18:03:45 CEST] <Amitari> Ah, there!
[18:03:47 CEST] <Amitari> Thanks! :D
[18:03:56 CEST] <Amitari> This will go in my command collection. :P
[18:03:58 CEST] <sb_> I've got a local mp4, trying to examine the atom structure programmatically (looking for a user-data atom sibling of moov.trak).  I've looked at how atom/boxes are read in libavformat/mov.c but don't know if there's any api for getting that info
[18:05:53 CEST] <kepstin> sb_: as far as I know, there isn't, that sort of thing's all abstracted away behind the libavformat interface.
[18:06:57 CEST] <kepstin> sb_: depending what's in the atom you're looking for, it might make sense to extend the mov demuxer to attach it to the stream as metadata
[18:07:06 CEST] <kepstin> (or it might already be there, I dunno)
[18:07:30 CEST] <sb_> its already supported, its the ISO uuid container
[18:08:09 CEST] <sb_> (are you saying it should be injected in AVPacket metadata when I'm in the av_read_frame loop?)
[18:14:08 CEST] <kepstin> hmm. the only thing I see the mov atom used for reading stream bitrate from isml, and xmp metadata. It's checking against an explicit list of uuid, and does nothing if it's not one of those two.
[18:14:13 CEST] <kepstin> the mov uuid atom*
[18:15:36 CEST] <kepstin> so if you're looking for a different type of data than one of those, it'll require extending the demuxer.
[18:16:57 CEST] <sb_> kepstin: oh I see, so I can add my own uuid_whatever inside mov_read_uuid and just add another else condition?
[18:17:21 CEST] <sb_> (and use av_dict_set to add some metadata of my own)
[18:19:17 CEST] <kepstin> sb_: yeah, that's probably the easiest way to do it.
[18:19:37 CEST] <kepstin> if it's something generically useful, the patch for that would probably be accepted, too.
[18:20:10 CEST] <sb_> yeah I was going to say.. its to add support for spherical video, its currently an RFC draft from google though
[18:20:14 CEST] <sb_> https://github.com/google/spatial-media/blob/master/docs/spherical-video-rfc.md
[19:53:34 CEST] <playajames> Anyone here with xuggler knowledge? Their IRC has noone in it :S
[19:56:05 CEST] <durandal_1707> what is xuggler?
[20:04:51 CEST] <playajames> A java library that allows FFMPEG to be used from java applications.
[20:37:28 CEST] <gnome1> ffmpeg picks (for libx264) the "high" profile, is this going to be more demanding to play than "main"?
[20:43:46 CEST] <rrva> if I have an AVFrame struct, how do I determine if I have a IDR frame in h264? is this just pict_type=I ?
[20:45:05 CEST] <sb_> rrva: do you have a handle on the stream?
[20:45:20 CEST] <rrva> yes
[20:45:44 CEST] <sb_> av_stream_get_parser will produce an AVCodecParserContext which has a key_frame flag
[20:46:14 CEST] <DHE> gnome1: it is more demanding, but unless you're dealing with cell phones, it's not likely to be an issue for playback
[20:46:34 CEST] <rrva> sb_: https://gist.github.com/rrva/471a0f106f67e380ca76ce3759b33a18
[20:47:02 CEST] <rrva> there is key_frame on both AVPacket and AVFrame level also
[20:47:11 CEST] <DHE> rrva: there should be a key_frame field. that'll be a proper IDR
[20:47:23 CEST] <DHE> h264 allows an I-frame which is not IDR
[20:48:09 CEST] <furq> gnome1: it's only likely to be an issue if you have a device which can't decode high profile
[20:48:21 CEST] <furq> and those are getting rare these days
[20:49:00 CEST] <rrva> DHE: key_frame on AVPacket level, that ought to be a an I-Frame (RAI random access indicator), and key_frame on AVFrame level is IDR then?
[20:49:28 CEST] <DHE> RAI is an mpegts thing. it's how it indicates clients can start playback from this point
[20:49:43 CEST] <rrva> yes, this is h264 in mpegts
[20:49:44 CEST] <DHE> but for example, in mpeg2 an I-frame is the same thing
[20:50:04 CEST] <DHE> but since h264 can have more than 1 reference frame you can have an I-frame that isn't seek-safe
[20:50:43 CEST] <rrva> i was thinking since avpacket level is available without any knowledge of video, it must be just signaling that it's an I-frame
[20:51:24 CEST] <rrva> avpacket->flags & AV_PKT_FLAG_KEY
[20:52:54 CEST] <rrva> so is there a difference between AVFrame->key_frame and AVCodecParserContext->key_frame ?
[20:54:07 CEST] <sb_> You can get the AVCodecParserContext without decoding a frame
[20:54:28 CEST] <rrva> aha
[20:55:03 CEST] <gnome1> DHE: furq: ok, I just want to avoid making some video that requires a 3GHz cpu just because I didn't pick the right profile :-D
[20:55:07 CEST] <rrva> and AVCodecParserContext->key_frame will be 1 iff i have an IDR only?
[20:55:20 CEST] <gnome1> but I suppose the bottleneck is going to be the bitrate and frame size
[20:55:33 CEST] <gnome1> (it's nice if I can play the videos also on a lower-spec computer (laptop), for example)
[20:55:51 CEST] <sb_> rrva I couldn't tell you definitively for IDR but definitely for h.264 i-frames
[20:56:28 CEST] <rrva> ok. I need something to tell me if it is IDR or not, maybe I should read more ffmpeg code.
[20:57:53 CEST] <rrva> sb_: it's set to 1 for more than IDR
[20:57:57 CEST] <rrva> sb_: "recovery_frame_cnt from SEI message
[20:59:41 CEST] <DHE> there is an h264 mode which doesn't have keyframes in the traditional sense. periodically a full frame partial refresh will occur such that if you decode the whole refresh sequence you get a working frame for presentation purposes
[21:00:07 CEST] <DHE> the main use is so that the I-frames are not so large by stretching them out over multiple frames
[21:01:22 CEST] <furq> gnome1: i have a core duo laptop from ~2006 which plays high profile 1080p fine
[21:01:56 CEST] <furq> it's really only a concern if you're dealing with hardware decoders which will just refuse to touch certain profiles
[21:02:21 CEST] <furq> iirc very old iphones will only play baseline profile
[21:05:17 CEST] <rrva> I believe, after reading https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264_parser.c that I can access H264ParseContext
[21:05:25 CEST] <rrva> and get IDR info from there
[21:05:54 CEST] <gnome1> I think I've had some issues with my laptop in the past, but that was probably too large (frame size, and thus bitrate) videos (these days even getting something from a site like youtube in 9000KHD can be easier than getting something more manageable)
[23:51:42 CEST] <AleXoundOS> Hi. Is it possible to edit loglevel "info" format?
[23:53:02 CEST] <JEEB> please note in more detail. it is possible to control with the API where those messages get pushed and you can create wrappers around that IIRC, but you cannot modify the messages themselves
[23:55:27 CEST] <AleXoundOS> I use latest ffmpeg from git. And "info" loglevel contains additional "speed" field that I don't need. Can I suppress it somehow?
[23:55:52 CEST] <JEEB> what
[23:56:17 CEST] <furq> grep -v speed
[23:56:48 CEST] <JEEB> oh
[23:56:52 CEST] <JEEB> that one line in ffmpeg.c
[23:57:19 CEST] <AleXoundOS> furq, this will suppress the whole line
[23:57:46 CEST] <AleXoundOS> JEEB, so there is no option controlling the "info" format, do you suggest to edit ffmpeg.c ?
[23:58:55 CEST] <JEEB> as far as I can tell print_report() gives no option for that
[23:59:13 CEST] <JEEB> you can probably disable that report printing altogether tho
[23:59:40 CEST] <JEEB> not sure why you'd want to completely disable it, though
[23:59:57 CEST] <JEEB> even if you are parsing the command line output it should be possible to update your stuff against the new output
[00:00:00 CEST] --- Sat Apr  2 2016