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

[burek]

[00:03:27 CEST] <kepstin> note that if you're encoding to dvd, the framerate must be 30 or 25 (ntsc/pal) and there's a keyframe every 18 or 15 frames. The requirement for keyframes so often means you can't make the video very small :/
[00:09:17 CEST] CTCP VERSION:  from fnodeuser (fnodeuser!025687e8 at gateway/web/freenode/ip.2.86.135.232) to #ffmpeg
[01:53:26 CEST] <ochoa> Hello
[01:54:24 CEST] <ochoa> is the only way to enable rtmpe and rtmpte protocols at install?
[01:54:56 CEST] <DHE> adding features to ffmpeg is only available at compile-time
[01:57:37 CEST] <ochoa> oh, but the arch package doesn't have them, so the only option is compiling from source, right?
[02:13:26 CEST] <ochoa> so i have to ./configure --enable-librtmp --enable-protocol=rtmpe --enable-protocol=rtmpte
[02:13:54 CEST] <c_14> are you sure those protocols aren't available?
[02:14:00 CEST] <c_14> checked `ffmpeg -protocols' ?
[02:14:11 CEST] <c_14> They should be enabled in a default build unless you explicitly disable them
[02:14:52 CEST] <c_14> or not
[02:14:55 CEST] <c_14> hmm
[02:14:58 CEST] <c_14> One of my builds has them, the other doesn't
[02:15:27 CEST] <ochoa> i have every rtmp variant except the encrypted ones
[02:15:51 CEST] <c_14> Ah, that's probably it
[02:15:58 CEST] <c_14> You have to build with openssl/gnutls probably
[02:16:14 CEST] <ochoa> oh, i didn't build from source at the start
[02:16:25 CEST] <ochoa> i installed from the arch packages
[02:16:39 CEST] <c_14> They are probably linked against gnutls
[02:16:45 CEST] <c_14> You might need to link against openssl
[02:17:19 CEST] <c_14> ffrtmpcrypt_protocol_deps_any="gcrypt gmp openssl"
[02:17:27 CEST] <c_14> So any of openssl/gcrypt/gmp
[02:17:42 CEST] <c_14> or librtmp
[02:17:45 CEST] <c_14> Whichever is easier for you
[02:18:07 CEST] <ochoa> i have librtmp, just not enabled in ffmpeg
[02:18:19 CEST] <c_14> then just enable that during configure
[02:18:33 CEST] <ochoa> so, i uninstall first
[02:18:58 CEST] <ochoa> then run the ./configure --enable-librtmp
[02:19:06 CEST] <ochoa> then make sudo make install?
[02:19:19 CEST] <c_14> you can install both at the same time as long as you put them in a different prefix and put the one you want to prefer ahead of the other in your PATH
[02:19:29 CEST] <c_14> and I'd recommend make -j8; sudo make install
[02:19:37 CEST] <c_14> just to minimize the amount of time it's running as root
[02:21:56 CEST] <ochoa> i do wonder why the encrypted rtmps are not supported by default
[02:24:34 CEST] <c_14> because you need openssl/gcrypt/gmp/librtmp to handle the encryption stuff (though ffmpeg does have some internal encryption stuff as well. afaik at least some AES)
[02:24:43 CEST] <c_14> the most probably reason is that nobody ever implemented it
[02:25:30 CEST] <c_14> Oh, btw none of the ffmpeg encryption procedures are tested/aimed at being good against side-channel attacks and/or timing attacks
[02:25:38 CEST] <c_14> Just going to throw that out there
[02:26:32 CEST] <ochoa> yeah, so you say i should install them and see if it goes?
[02:26:58 CEST] <c_14> ye, pick any one you like, enable the corresponding configure option and build it
[02:27:19 CEST] <ochoa> but i already have librtmp!
[02:27:39 CEST] <ochoa> didn't work last time
[02:28:14 CEST] <c_14> did you enable the configure option?
[02:28:38 CEST] <ochoa> last time i enabled rtmpte and rtmpe protocols but not the library
[02:28:54 CEST] <c_14> yeah, those options never fail (even if they should)
[02:29:42 CEST] <c_14> (by those options I mean --enable-protocol, --enable-encoder etc)
[02:30:21 CEST] <ochoa> the thing is the compiled from source ffmpeg didn't work
[02:30:30 CEST] <ochoa> had to go back to the package one
[02:30:35 CEST] <c_14> didn't work how?
[02:31:09 CEST] <ochoa> one of the libraries
[02:31:11 CEST] <ochoa> was missing
[02:31:51 CEST] <c_14> which one? one of the libav* libraries? or an external one?
[02:32:12 CEST] <c_14> And this during library-resolution at run-time by ld.so, right?
[02:32:23 CEST] <ochoa> yeah
[02:32:36 CEST] <ochoa> but i don't remember which library, it was like 2 hours ago
[02:32:52 CEST] <c_14> did you pass --enable-shared?
[02:33:18 CEST] <c_14> or set --extra-ldflags?
[02:33:18 CEST] <ochoa> no
[02:33:50 CEST] <ochoa> no, damn
[02:34:00 CEST] <c_14> hmm, then it should have worked
[02:34:15 CEST] <ochoa> that's what puzzles me
[02:35:22 CEST] <ochoa> i'm redoing the ./configure --enable-librtmp --enable-protocol=rtmpe --enable-protocol=rtmpte
[02:37:11 CEST] <ochoa> just that, no other flags
[03:51:13 CEST] <n1cky> anyone have advice for creating subtitle files? I have a transcript, and I'd like to do it word-by-word.
[03:51:35 CEST] <n1cky> I was thinking I could take vim and put each word on its own line, then write a macro that pipes to a shell command and somehow gets the timestamp from mpv
[03:51:46 CEST] <n1cky> then goes to the next one
[03:52:01 CEST] <n1cky> so all I would have to do is tap every time that a word is spoken
[03:52:16 CEST] <n1cky> Any better solution is appreciated.
[03:52:49 CEST] <ochoa> hmmmm
[03:53:17 CEST] <ochoa> remember that you also have to let the sub file know when to stop
[03:53:53 CEST] <ochoa> .srt works by first saying the start-end of a certain text and then the text itself
[03:55:32 CEST] <n1cky> Good call. But I don't think that's a big problem if I do the first and last timestamp by hand
[03:56:00 CEST] <ochoa> hmmm
[03:56:11 CEST] <ochoa> maybe make it on hold/release?
[03:56:45 CEST] <ochoa> start on press stop on release
[08:55:21 CEST] <pezet91> hello ;)
[08:55:52 CEST] <pezet91> how to convert FICV video to MP4?
[09:26:46 CEST] <nifwji2> what the hell is that format?
[09:28:03 CEST] <nifwji2> it looks like it comes from some crappy looking screen recorder.
[09:42:41 CEST] <Fyr> guys, I need to create title and credits, like in movies.
[09:43:10 CEST] <Fyr> FFMPEG is a pretty heavy tool to create such things.
[09:43:41 CEST] <JEEB> I usually used to use Aegisub to create ASS subtitles which have a bunch of text scrolling
[09:43:55 CEST] <JEEB> then just burned that into a clip with whatever app I had on hand
[09:44:09 CEST] <Fyr> is there a simple open-source video editing tool?
[09:44:12 CEST] <furq> https://www.shotcut.org/
[09:44:13 CEST] <furq> hf
[09:44:32 CEST] <Fyr> ok
[09:44:46 CEST] <Fyr> it's called "Text overlay?"
[09:44:58 CEST] <furq> i've never used it
[10:14:54 CEST] <nifwji2> okay
[10:15:06 CEST] <nifwji2> http://i.4cdn.org/wsg/1465805628945.webm
[10:15:11 CEST] <nifwji2> take a look at this animation
[10:15:22 CEST] <nifwji2> the black and white pixels are super sharp
[10:15:36 CEST] <nifwji2> but the blue and red are really blurry for some reason.
[10:15:46 CEST] <nifwji2> is there a reason why this is happening?
[10:17:09 CEST] <nifwji2> this is the command I am using http://pastebin.com/En9xzBLy
[10:17:41 CEST] <JEEB> without watching the clip the one thing I can tell you about is chroma subsampling. after that there's probably also vp8/vp9 encoder being crappy at the rates you're using (aka "it's just lossy compression, baby)
[10:18:03 CEST] <nifwji2> the original file is completely lossless right
[10:18:07 CEST] <nifwji2> or files
[10:18:25 CEST] <nifwji2> and there total size is only a few megabytes
[10:19:04 CEST] <nifwji2> it is a 256x192 animation
[10:19:12 CEST] <nifwji2> with a total of 4 colours
[10:19:31 CEST] <JEEB> if it's pixel art or something, I recommend scaling with nearest neighbor to 2x width and height
[10:19:38 CEST] <nifwji2> it isn't pixel art though.
[10:19:44 CEST] <nifwji2> it was just animated on a nintendo dsi
[10:19:49 CEST] <nifwji2> and that is the screen resolution
[10:20:13 CEST] <nifwji2> I think the problem is caused by the encoding.
[10:20:17 CEST] <JEEB> well, in any case if you want to keep the color somewhat better, then do that to work "around" chroma subsampling part
[10:20:25 CEST] <JEEB> if the encoder is just bad at compression, it won't fix that
[10:20:33 CEST] <JEEB> but it should make the reds/blues better
[10:20:49 CEST] <JEEB> read about 4:2:0 chroma subsampling and you'll understand
[10:24:08 CEST] <nifwji2> I don't know exactly what that is
[10:24:13 CEST] <nifwji2> but I read a little bit
[10:24:59 CEST] <nifwji2> and I couldn't quite understand it
[10:25:40 CEST] <nifwji2> I will look more into it later.
[10:27:27 CEST] <nifwji2> it seems encoding at a high quality can be quite difficult.
[10:27:43 CEST] <nifwji2> especially if you don't know what you are doing.
[10:36:06 CEST] <vladashram> Which container is better for streaming, m2ts, ts, or mkv?
[10:36:36 CEST] <JEEB> both of the two first ones are the same
[10:36:43 CEST] <JEEB> m2ts just usually means 192 byte packets
[10:36:49 CEST] <JEEB> and "normal" mpeg-ts is 188 byte
[10:38:46 CEST] <vladashram> Wouldn't larger packets be better for streaming though?
[10:39:20 CEST] <JEEB> not really, considering what the difference is
[10:39:32 CEST] <JEEB> since most of the data is the same, it's just four bytes for checksum
[10:39:38 CEST] <vladashram> I guess, 4 byes is pretty nothing.
[10:39:51 CEST] <JEEB> so if you like your checksums you can use 192 byte :)
[10:39:55 CEST] <nifwji2> I just played the output with ffplay.
[10:39:57 CEST] <nifwji2> omg
[10:40:06 CEST] <nifwji2> the blue and red pixels are being so screwed up.
[10:40:12 CEST] <JEEB> nifwji2: never think of ffplay as a reference
[10:40:16 CEST] <JEEB> use mpv as rendering reference
[10:40:21 CEST] <nifwji2> I am using ffplay
[10:40:29 CEST] <JEEB> don't
[10:40:37 CEST] <JEEB> it's bad, it's a Proof of Concept
[10:40:47 CEST] <nifwji2> because all my other media players render the video blurry  in fullscreen
[10:41:00 CEST] <nifwji2> but ffplay has it much more sharp.
[10:41:18 CEST] <JEEB> probably because it does things in a bad way which you're seeing there :P
[10:41:35 CEST] <nifwji2> the video looks much better in ffplay
[10:41:48 CEST] <nifwji2> I am just using it to see how the individual pixels easier.
[10:42:26 CEST] <nifwji2> trying to encode videos at such a low resolution
[10:42:39 CEST] <nifwji2> that need to be completely lossless.
[10:42:46 CEST] <nifwji2> otherwise they don't look good.
[10:42:56 CEST] <nifwji2> not that they really look that great normally.
[10:43:11 CEST] <nifwji2> I will figure it out later.
[10:45:47 CEST] <nifwji2> something I kind of find funny.
[10:46:44 CEST] <nifwji2> is how the thing I used to play a video file effects the quality more than how it was encoded or it's bitrate.
[10:47:23 CEST] <nifwji2> I have watched dvd's before.
[10:47:29 CEST] <nifwji2> and on the dvd player they look horrible
[10:47:40 CEST] <nifwji2> but on the computer the files look really good.
[10:47:50 CEST] <nifwji2> or if you just copy the audio file onto a usb and play it using the tv
[10:47:55 CEST] <nifwji2> I meant video file
[10:48:15 CEST] <nifwji2> the video quality gets screwed up because of the cheap dvd player.
[10:48:31 CEST] <nifwji2> sending a crappy signal that isn't even the right framerate to the tv
[10:48:46 CEST] <nifwji2> and some other things effect the quality
[10:49:04 CEST] <nifwji2> but I don't know much about how video works.
[10:50:08 CEST] <nifwji2> I have noticed differences between video and music players.
[11:01:07 CEST] <nifwji2> so far I have decoded and uploaded 75 animations from flipnote hatena
[11:01:14 CEST] <nifwji2> out of the 7000 I have
[11:02:45 CEST] <nifwji2> I just reverse image searched a thumbnail.
[11:03:06 CEST] <nifwji2> and the search returned some results to an image that contained the thumbnail.
[11:03:19 CEST] <nifwji2> how does google even do that?
[11:03:38 CEST] <nifwji2> how could they possibly search images that quickly?
[11:07:34 CEST] <arthcp> thats the whole secrete
[11:09:55 CEST] <nifwji2> I wonder if nintendo will make a new ds that supports homebrew without needing an exploit.
[11:10:07 CEST] <nifwji2> I don't wonder that.
[11:10:11 CEST] <nifwji2> because that would never happen.
[11:10:51 CEST] <nifwji2> they don't want people running anything they didn't intend on their consoles.
[11:11:29 CEST] <nifwji2> because that would allow people to pirate everything.
[11:15:17 CEST] <anddam> I have a 1920x1080 h.265 video that I want to scale down, from https://trac.ffmpeg.org/wiki/Scaling%20(resizing)%20with%20ffmpeg I tried  -vf scale=-1:480 after my -c:v options and I got
[11:15:20 CEST] <anddam> "x265 [error]: Picture width must be an integer multiple of the specified chroma subsampling"
[11:16:02 CEST] <anddam> I see that being the original source 1920x1080 the 480p wide format would be 853.34 and that's not integer
[11:16:21 CEST] <anddam> what's the proper approach here, should I just scale it by half to 540 vertical points?
[11:16:26 CEST] <JEEB> switch -1 to -2
[11:16:31 CEST] <JEEB> that makes sure it's divisible by two
[11:16:32 CEST] <anddam> I'm scaling down this since an older ipad cannot hand that size
[11:16:42 CEST] <JEEB> also are you sure your ipad can play HEVC?
[11:16:49 CEST] <anddam> i'm sure
[11:16:50 CEST] <JEEB> AVC I know it does
[11:17:06 CEST] <anddam> it's an ipad2 and VLC on it does even 720p
[11:17:10 CEST] <anddam> HEVC
[11:17:16 CEST] <anddam> but I don't need it and prefer to save some space
[11:17:53 CEST] <anddam> JEEB: ok -2 works, care to elaborate why? I mean what's divisible by two now?
[11:18:18 CEST] <anddam> wow, a wopping 15 fps
[11:18:20 CEST] <JEEB> width
[11:18:31 CEST] <anddam> ah it's 854x480 now
[11:18:33 CEST] <JEEB> the first param of scale is width, the second is height
[11:18:47 CEST] <anddam> I wasn't sure if using a "known" height was better or not
[11:18:57 CEST] <anddam> i.e. if using 480 or 720 rather than <any integer number>
[11:20:01 CEST] <kyven> is there an api to convert avcodecparameters to avcodeccontext in ffmpeg
[11:22:00 CEST] Last message repeated 1 time(s).
[11:22:00 CEST] <anddam> ah better, dorpped to 8fps
[11:23:02 CEST] <nifwji2> why doesn't 4chan allow me to upload vp9 webms?
[11:23:13 CEST] <nifwji2> there is no reason why I shouldn't be able to.
[11:23:56 CEST] <anddam> nifwji2: that's an odd question for this channel
[11:24:07 CEST] <nifwji2> oh
[11:24:13 CEST] <nifwji2> I didn't want to bother switching channels
[11:24:22 CEST] <nifwji2> and it had to do with encoding.
[11:24:43 CEST] <anddam> that's a safe policy on irc where people are hardly ever annoyed by other people laziness
[11:36:04 CEST] <anddam> that sounded more polemic than I meant
[11:36:20 CEST] <anddam> what I mean is that 4chan upload policy are hardly a common topic here
[11:55:11 CEST] <nifwji2> becausse of how fiddely ffmpeg is and I am not very good with it.
[11:55:27 CEST] <nifwji2> I try not to touch the videos I upload to youtube as much as possible.
[11:55:46 CEST] <nifwji2> which means that apart from changing the codec and the bitrate
[11:55:56 CEST] <nifwji2> I don't do anything else.
[11:56:21 CEST] <nifwji2> I usually download all of my youtube video in 1080p
[11:56:41 CEST] <nifwji2> but since I haven't had much luck with lowering resolution while keeping a decent quality.
[11:56:47 CEST] <nifwji2> I just keep it at 1080p
[11:57:03 CEST] <nifwji2> luckily all of the webms I have made so far have been 2 seconds long.
[11:58:15 CEST] <nifwji2> I download in highest quality always.
[11:58:26 CEST] <nifwji2> even if it is in 4k.
[11:58:51 CEST] <nifwji2> unless it is a let's play that I don't care about.
[11:58:54 CEST] <nifwji2> then I download in 360p
[11:59:23 CEST] <nifwji2> and the only reason I am downloading it in the first place is because my laptop can't handle youtube.
[11:59:27 CEST] <nifwji2> my other laptop I mean.
[12:55:25 CEST] <Fyr> is it possible to reduce framerate, keeping quality?
[13:28:11 CEST] <nifwji2> I am about to start work on a script that will take a link off of sudomemo
[13:28:27 CEST] <nifwji2> and then download the ppm file for it
[13:28:32 CEST] <nifwji2> then encode the file into a webm
[13:29:03 CEST] <nifwji2> this is gonna be a bit more difficult than my previous script.
[13:29:44 CEST] <nifwji2> considering I need to download a html file and then copy certain strings from it.
[13:29:55 CEST] <nifwji2> but I think it will be a fun project.
[13:31:06 CEST] <nifwji2> I think python would be the optimal language too use for scripting this.
[13:31:22 CEST] <nifwji2> but I want to use batch because it is easier.
[15:00:45 CEST] <georgios> mpeg2 must be more stupid than i thought. all it has to do is repeat one frame for 20minutes 15 times.
[15:00:51 CEST] <georgios> -f dvd -r 25 -vf scale=720:576 -aspect 16:9 -minrate 0 -maxrate 8000k -muxrate 10080000 -g 15 -bufsize 1835008 -packetsize 2048 -trellis 1 -me_range 63 -acodec ac3 -ab 192k -ar 48000 -vcodec mpeg2video -vb 5000k
[15:01:10 CEST] <georgios> produces poor video
[15:02:41 CEST] <georgios> this is what kdenlive
[15:10:07 CEST] <georgios> *uses
[15:32:11 CEST] <georgios> can mpeg2 have a vbr?
[15:42:34 CEST] <Kadigan> Hi. I wanted to know if there was a simple way of converting variable frame rate video to constant frame rate. I have a bucketload of .mkv anime files (VFR tends to be used heavily there) and they are a pain to watch with SVP which creates smooth motion - but drops the entire buffer when a framerate change is detected. I don't mind it being time- and/or space-consuming, but would love it to be sure-fire (>360 files).
[15:46:43 CEST] <Kadigan> Okay, so it doesn't even have to be simple. It has to be automatic though. I don't mind spaghetti command lines, but I won't be able to spend time inspecting each output and making decisions.
[16:21:25 CEST] <Fyr> guys, why does ffprobe not show it if the audio encoded with constant bitrate or variable?
[16:21:41 CEST] <Fyr> it shows only bitrate.
[16:26:08 CEST] <DHE> sometimes you don't even get that. knowing the actual bitrate may require reading the whole file to find the timestamps, then doing the math.
[16:28:00 CEST] <furq> can't you just check if bit_rate == max_bit_rate
[16:28:37 CEST] <Fyr> ?
[17:36:23 CEST] <kepstin> georgios: when you're encoding for DVD, it needs 25 frames per second, and keyframe every 15 frames (2 per second) (for PAL). As a result, it *can't* just repeat one frame.
[17:36:41 CEST] <kepstin> georgios: nothing you can do about it if you want dvd-compliant video
[17:38:50 CEST] <furq> i'd have thought it would still compress well though
[17:44:55 CEST] <kepstin> depends on the complexity of the frame, I suppose. If it's a complex image, it'll spend as many bits as possible on the keyframe (given the vbv settings), then use the predicted frames to improve it :/
[17:51:27 CEST] <hanshenrik> som1 claims that chopping up videos into jpg's then feeding it back into ffmpeg in reverse to make a video again, is better than using the "reverse" filter because
[17:51:35 CEST] <hanshenrik> >This method is still better than ffmpeg's reverse filter, which buffers all the frames in RAM, uncompressed. A 1080p video that is 33mb and 2 minutes long uses 10gb ram.
[17:51:46 CEST] <hanshenrik> any truth to that?
[17:52:08 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#reverse_002c-areverse
[17:52:51 CEST] <hanshenrik> but is it true that the "reverse" filter use an insane amount of ram for movies>30mb?
[17:54:47 CEST] <ChocolateArmpits> That wouldn't make sense
[17:55:01 CEST] <ChocolateArmpits> Would be smarter to buffer couple of seconds at a time
[17:55:38 CEST] <hanshenrik> idd i suppose
[17:56:03 CEST] <ChocolateArmpits> >This filter requires memory to buffer the entire clip, so trimming is suggested.
[17:56:09 CEST] <ChocolateArmpits> welp
[17:56:47 CEST] <hanshenrik> ...why?
[17:59:37 CEST] <kepstin> hanshenrik: it's just because of how filters work in ffmpeg; they can't seek in the incoming video stream, they only get frames in order
[18:00:04 CEST] <kepstin> so to reverse the video, a filter has to buffer from the start to the end, then output frames from the end to the start.
[18:00:41 CEST] <hanshenrik> a limitation in the... filter api? or something?
[18:01:04 CEST] <kepstin> filter api simply isn't designed for this sort of thing, and I don't think it really makes sense to change
[18:01:38 CEST] <kepstin> it might be possible to add a 'trick play' mode into, say, the ffmpeg tool itself to play (seekable) videos backwards.
[18:01:39 CEST] <ChocolateArmpits> filtering is linear, I guess there should be a reverse input option
[18:02:07 CEST] <ochoa> I compiled ffmpeg from source, but now when i want to use mpv it goes
[18:02:09 CEST] <ochoa> mpv: error while loading shared libraries: libavfilter.so.6: cannot open shared object file: No such file or directory
[18:02:23 CEST] <furq> did you also compile mpv from source
[18:02:47 CEST] <ochoa> no
[18:03:05 CEST] <furq> well there's your problem
[18:03:24 CEST] <ochoa> ok
[18:03:31 CEST] <furq> either build ffmpeg static so it doesn't screw up your system libraries, or rebuild mpv whenever you build ffmpeg
[18:03:40 CEST] <furq> probably the first one
[18:04:19 CEST] <ochoa> build ffmpeg static?
[18:04:32 CEST] <furq> ./configure --enable-static
[18:05:14 CEST] <ochoa> oh man
[18:05:21 CEST] <ochoa> so i have to build it again?
[18:06:43 CEST] <furq> how did you install mpv
[18:06:54 CEST] <ochoa> arch packages
[18:07:25 CEST] <ochoa> same as ffmpeg, just that i compiled from source to get support for the encrypted rtmp protocols
[18:08:26 CEST] <furq> does arch let you build custom packages or something
[18:08:46 CEST] <furq> normally you'd still have the libav* libs if you compiled ffmpeg from source
[18:09:04 CEST] <furq> "normally" meaning on a distro i understand
[18:09:34 CEST] <ochoa> yeah i have them
[18:10:01 CEST] <ochoa> even when i run ffmpeg it shows libavfilter 6.
[18:10:45 CEST] <furq> does the .so show up in /usr/lib
[18:10:49 CEST] <furq> or wherever arch installs libs
[18:16:25 CEST] <ochoa> there's libavahil tho
[18:16:28 CEST] <ochoa> weird
[18:17:33 CEST] <furq> libavahi is unrelated
[18:17:55 CEST] <furq> i guess you actually need to rebuild with --enable-shared then
[18:19:11 CEST] <ochoa> yeah, it would have to be later, i have a powerout in like 40 mins
[18:19:21 CEST] <furq> it sure is nice of arch to bundle all of these libs in the ffmpeg package instead of providing them separately
[18:19:25 CEST] <furq> and by nice i mean really stupid
[18:20:11 CEST] <ochoa> they also bundle ffmpeg with mpv
[18:20:43 CEST] <furq> well i assume that's just a dependency on the ffmpeg package
[18:20:53 CEST] <furq> whereas libav* aren't separate packages, they're provided by the ffmpeg package
[18:21:05 CEST] <furq> so i'm guessing you reinstalling ffmpeg has just blown that package away and now you don't have those libs any more
[18:21:17 CEST] <ochoa> yeah, that's what happened
[18:21:19 CEST] <furq> i'm not going to pretend to understand how pacman works though
[18:21:43 CEST] <furq> doesn't arch have something like ports where you can just customise the existing package
[18:21:55 CEST] <furq> abs?
[18:22:02 CEST] <ochoa> i think there is, but i don't like to mess with that much
[18:22:12 CEST] <furq> i assume that'll build with the right options as far as packaging is concerned, so you can just add the options you want
[18:22:18 CEST] <ochoa> btw i got it
[18:22:33 CEST] <ochoa> i just reinstalled mpv and it got the right hooks
[18:22:38 CEST] <furq> oh
[18:22:43 CEST] <furq> do you still have the ffmpeg you compiled
[18:22:56 CEST] <ochoa> and ffmpeg still has rtmpe and rtmpte enabled
[18:22:58 CEST] <ochoa> yeah
[18:23:00 CEST] <furq> weird
[18:23:01 CEST] <ochoa> just got the libs
[18:23:03 CEST] <furq> oh well i guess that works
[18:23:44 CEST] <ochoa> i would've liked to have libav as a separate package to prevent stuff like this tho
[18:24:07 CEST] <furq> yeah debian provides all the libs separately
[18:24:15 CEST] <ochoa> thanks so much furq you were really helpful
[19:27:58 CEST] <VarunAgw> General question about videos format. Do html5 web formats like webm, mp4 have generally constant vbr? Also if I understood correctly, constant vbr means seeking through x frames will always result in same duration seek through out the video?
[19:28:58 CEST] <Mavrik> "constant vbr"? Video bitrate?
[19:29:07 CEST] <VarunAgw> yes
[19:29:16 CEST] <VarunAgw> oops
[19:29:17 CEST] <Mavrik> Depends on your definition of "contstant" :)
[19:29:21 CEST] <VarunAgw> I mean video frame rate
[19:29:29 CEST] <Mavrik> Ah.
[19:29:46 CEST] <Mavrik> Yes, you most certanly want to have constant frame rate if you don't want player issues.
[19:29:48 CEST] <VarunAgw> I wanted to write vfr
[19:30:06 CEST] <Mavrik> While technically they should all support VFR, it's a great way to have bunch of strange problems and non-working seeks :)
[19:30:28 CEST] <VarunAgw> I am not creating videos. I am asking about the online videos available
[19:30:55 CEST] <VarunAgw> Am I safe to assume most videos online including youtube have constant frame rate
[19:31:38 CEST] <Mavrik> Uh.
[19:31:41 CEST] <Mavrik> Probably not.
[19:31:45 CEST] <furq> youtube videos certainly do
[19:31:50 CEST] <furq> i couldn't comment on anything else though
[19:31:59 CEST] <Mavrik> Since you'd be relying on everyone reencoding iPhone and other mobile videos :)
[19:33:29 CEST] <VarunAgw> Also is there any ffmpeg filter to seek by time? I found `select` but it seek by frame
[19:33:40 CEST] <georgios> kepstin: ugly news...
[19:33:58 CEST] <Mavrik> VarunAgw, uhh, seeking isn't done by filters.
[19:34:14 CEST] <Mavrik> It would be easier for us to help if you'd tell us what are you trying to do :)
[19:34:24 CEST] <VarunAgw> I found -r. But it is very slow compared to seek by time
[19:34:26 CEST] <kepstin> VarunAgw: there's 'trim', but it doesn't seek; it just throws away frames outside the selected time.
[19:34:34 CEST] <georgios> it seems i will need enormous space for about 10h of audio
[19:34:56 CEST] <Mavrik> VarunAgw, -r?
[19:34:57 CEST] <kepstin> georgios: use a simpler picture. plain black screen should be nice and small.
[19:35:04 CEST] <Mavrik> That's a framerate setting O.o
[19:37:19 CEST] <georgios> kepstin: my sources are 11GB, maybe i can turn them into something that fits a dl-dvd and get the same feel
[19:51:58 CEST] <VarunAgw> Mavrik: Wait, I am trying something. I think I got this
[20:03:26 CEST] <pfelt> afternoon all. i'm playing with some multicast and decklink.  one multicast stream comes in at what looks like progressive ([SAR 1:1 DAR 16:9], 59.94 fps, 59.94 tbr, 90k tbn) and one comes in interlaced ([SAR 1:1 DAR 16:9], 29.97 fps, 59.94 tbr, 90k tbn).  the interlaced stream, when output to a decklink card runs very choppy, but the progressive does not
[20:03:41 CEST] <pfelt> are there any good diags that i can run to figure out why?
[20:07:29 CEST] <Kadigan> pfelt: are You sure the other input is actually interlaced? I've seen Canon XC10 randomly switch between interlacing and "I'll split progressive frames into fields and call it interlacing"
[20:08:44 CEST] <Kadigan> that "29.97 fps, 59.94 tbr" makes me believe it's progressive video being sold as interlaced (when it's really not)
[20:10:25 CEST] <DHE> I thought you had to actually decode the frames and read the interlaced setting on each one
[20:11:52 CEST] <pfelt> Kadigan: i'm fairly sure that it's interlaced and that it's not changing.
[20:12:03 CEST] <pfelt> DHE: is there any good way to find out?
[20:12:38 CEST] <Kadigan> pfelt: decode two fields separately into images and see if there's temporal difference between them
[20:13:33 CEST] <georgios> kepstin: i used the same commandline for dvd video and selected 15fps
[20:13:54 CEST] <pfelt> Kadigan: i'm using ffmpeg and not my own app.  is there a way to get ffmpeg to do that for me?
[20:14:02 CEST] <pfelt> (recent git)
[20:14:04 CEST] <Kadigan> pfelt: of course there is.
[20:14:17 CEST] <kepstin> georgios: you can't put 15fps video on a dvd, though. It has to be 25 (actually 50 fields/s) for PAL.
[20:14:35 CEST] <kepstin> (I mean, some players might play it - maybe? but I wouldn't bet on it)
[20:14:45 CEST] <georgios> hmm, ffmped let me though. yes..
[20:26:06 CEST] <Kadigan> pfelt: `ffmpeg -i input -filter:v "field=0" -frames:v 1 ./out.png` for top frame
[20:26:15 CEST] <Kadigan> pfelt: `ffmpeg -i input -filter:v "field=1" -frames:v 1 ./outb.png` for bottom frame
[20:27:16 CEST] <Kadigan> Seek around using -ss HH:MM:SS.nn until You find a place where there's temporal difference between the top and bottom fields (a sure-fire mark of interlaced video)
[20:28:32 CEST] <Kadigan> OR, output 2min of just-top frames through `-frames:v 3600 -filter:v "field=0" ./frame-%4d-top.png`, and then just bottom via `-frames:v 3600 -filter:v "field=1" ./frame-%4d-bottom.png`
[20:28:34 CEST] <Kadigan> or something.
[20:29:42 CEST] <Kadigan> and go field-by-field to confirm a "comb effect"
[20:29:48 CEST] <Kadigan> (I'm sure You know what to look for?)
[20:31:18 CEST] <Kadigan> georgios: I'm sure ffmpeg will let You, but I'm not so sure DVD players will play that content properly.
[20:33:05 CEST] <Kadigan> pfelt: I'm not sure if that's what it is in Your case; all I'm sure is that once I put some of my own video (from the XC10) through YADIF, some of it came out fine, while a few files came out choppy as all hell. Turned out that those source files were progressive disguised as interlaced. I suppose the camera didn't have enough time to process fields, so it went w/ frames.
[20:33:44 CEST] <Kadigan> I must also assume that Black Magic cards will take whatever you put into them and do whatever you tell them to do, regardless of their 'better judgement', because that's what pro cards can - and will - do.
[20:34:04 CEST] <pfelt> Kadigan: i'll try that in just a sec.  i pulled out a tektronix analyzer to see if it'll tell me
[20:34:41 CEST] <Kadigan> Hm, I'm not sure if that'll help though, since the signalling will be perfectly legal for interlaced video.
[20:34:50 CEST] <Kadigan> It's just that the fields won't have temporal separation.
[20:35:02 CEST] <Kadigan> (ie. when You combine them, they'll form perfect progressive frames)
[20:36:32 CEST] <pfelt> Kadigan: ok.  so on the smooth video tek shows it as 720p.  the choppy one shows as 1080i
[20:38:17 CEST] <Kadigan> That doesn't tell me anything unfortunately, because I've never even seen such an analyzer :)
[20:38:31 CEST] <pfelt> well, it's detecting the one as progressive and the other as interlaced
[20:38:48 CEST] <Kadigan> If You have PTS, You can check the granularity. If it's 1/59.94th then maybe interlaced; if 1/29.97th absolutely progressive.
[20:38:54 CEST] <pfelt> as for your two commands i'll need to save off the stream so i can get the same first frame&  standby
[20:39:43 CEST] <Kadigan> What's the stream coming off of? Direct video from a camera, or some player?
[20:40:07 CEST] <pfelt> multicast direct feed from some hardware we have
[20:40:32 CEST] <Kadigan> Does it mangle or pass-thru from source?
[20:41:15 CEST] <Kadigan> Just make sure You have motion in the frame. :)
[20:41:19 CEST] <Kadigan> (this should go w/o saying)
[21:00:34 CEST] <DHE> using libav, I think I'm getting packets out of order. avcodec_decode_video2 is supposed to return the packets in PTS order, right?
[21:03:02 CEST] <Mavrik> DTS I think.
[21:03:18 CEST] <Mavrik> Ah.
[21:03:26 CEST] <Mavrik> decode_video should return them in PTS order yes
[21:05:33 CEST] <DHE> I'm getting broken video when the content is h264, but okay video for different codecs... some frame reordering would explain what I see...
[21:12:35 CEST] <Kadigan> pfelt: and?
[21:13:02 CEST] <Kadigan> DHE: for specific file or all h264 content?
[21:14:07 CEST] <Kadigan> Also, doesn't h264 use bi-directional frames that need to be decoded out of order?
[21:14:56 CEST] <DHE> Kadigan: this one example I have. my other test source is mpeg2 and it's fine (OTA receiver)
[21:15:28 CEST] <Kadigan> Check different file.
[21:17:59 CEST] <Kadigan> DHE: https://stackoverflow.com/questions/21649674/why-do-we-transmit-the-ibp-frames-out-of-order does this help at all? (I'm a fresh newb here)
[21:19:11 CEST] <pfelt> Kadigan: this one that's choppy is definitely interlaced, but when i run it through yadif it gets worse on choppiness
[21:20:18 CEST] <Kadigan> Have You found temporally-distinct fields?
[21:28:59 CEST] <DHE> Kadigan: I understand the problem, I just don't know what's causing it
[21:29:56 CEST] <Kadigan> I don't follow. You claim to understand the problem, and yet not at the same time? Bottom line: frames may be presented in incorrect PTS order; buffer and reorder them as needed.
[21:30:04 CEST] <Kadigan> -- that's what I understood, anyway.
[21:30:35 CEST] <Kadigan> As I understand it, this is not something that needs fixing, but rather watching out for and handling as it comes in.
[21:31:18 CEST] <Kadigan> If I misunderstood the problem, please correct me.
[21:34:33 CEST] <DHE> Kadigan: my understanding is that you give frames in DTS order from the demuxer (which is how they come) to the decoder and they come out in PTS order. you only need to deal with the fact that the decoder will hang onto frames before it starts giving you frames
[21:36:19 CEST] <DHE> normally ffmpeg will give errors if you do things blatently wrong like that, but I don't see any errors. just tearing video
[21:40:35 CEST] <Kadigan> "as said, for h264 with b frames you need the order _not_ "as demuxed" but "as decoded", and I'm not talking about any 'coded_picture_number' but about the order of the h264 frames as the decoder returns them. That is the correct order, and the pts should reflect that order. If it doesn't, trust the order the decoder gives you over the pts.
[21:40:35 CEST] <Kadigan> "
[21:41:42 CEST] <Kadigan> Otherwise, try ignoring out-of-order PTS and see what happens.
[21:42:32 CEST] <Kadigan> ( http://libav-users.943685.n4.nabble.com/Frame-order-from-TS-demux-mpeg2video-vs-h264-td4597204.html#a4598722 this is where I found this )
[22:50:14 CEST] <gro> Hey guys, i'm trying to debug ffmpeg_g to rebuild the "-acodec copy -vcodec copy" function but i'm not really good at it, do you have some tipps for me? Maybe some c example with the stream copy?
[00:00:01 CEST] --- Tue Jun 14 2016