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

[burek]

[00:00:41 CEST] <pZombie> crst usually they clock much higher with a good heatsink on, but mine was a lemon... i think the shop that sold it to me was pre-testing them
[00:01:02 CEST] <pZombie> mine goes max 4.2ghz whereas others have been up to 5ghz with some good cooling
[00:02:07 CEST] <pZombie> furq - the single core compressing makes sense however
[00:02:14 CEST] <pZombie> even though the differences are minimal
[00:02:45 CEST] <pZombie> actually, single thread, not single core
[00:03:29 CEST] <furq> the bit about multithreading is all over the place
[00:04:00 CEST] <pZombie> but it has some hidden truth in it for sure
[00:04:49 CEST] <crst> LEt's not forget the 45kb
[00:05:12 CEST] <crst> It's true
[00:05:43 CEST] <pZombie> 16,848,337 16 threads vs 16,824,065 bytes 1 thread this time
[00:05:45 CEST] <furq> http://forum.doom9.org/showthread.php?t=155585
[00:06:14 CEST] <pZombie> last time i think i was checking the size on disk rather than the size of the file itself
[00:06:46 CEST] <crst> It's less?
[00:06:54 CEST] <pZombie> yes, exactly my thoughts
[00:07:06 CEST] <pZombie> how can be the size on disk be less than the size of the file?
[00:07:21 CEST] <pZombie> when there is no compression enabled on my side
[00:07:25 CEST] <pZombie> or is there?
[00:07:29 CEST] <pZombie> hm, let me check
[00:07:58 CEST] <pZombie> ah yes, i had compression enabled on this disk
[00:08:26 CEST] <pZombie> anyway, so here you have it. The true difference is 24kb, not 45
[00:09:20 CEST] <Illya> Bray90820 yes
[00:09:39 CEST] <pZombie> you can test it for yourself, use a smaller size video maybe. Do one run with many threads using -threads <amount of threads> and a run with -threads 1
[00:09:53 CEST] <pZombie> the size of the resulting file with same settings will be different
[00:10:07 CEST] <crst> well, you have more room for a metadata entry at least
[00:11:21 CEST] <Bray90820> Illya: Yesterday you were asking if I ws using Macports and I said I did not install it that I know of
[00:12:02 CEST] <pZombie> if we find 100 such similar tweaks, we could save 2.4mb out of ~17
[00:14:09 CEST] <Bray90820> Illya: So where should I go from here
[00:15:18 CEST] <hyponic> can ffmpeg transcode teletext subtitles to dvbsubtitles?
[00:15:30 CEST] <Ilya> Bray90820: your installation seemed odd. could you do `find / -name ffmpeg 2>/dev/null` in a shell and put the output in a pastebin?
[00:16:00 CEST] <Ilya> did you, by chance, change the installation directory of homebrew?
[00:16:33 CEST] <Ilya> or maybe you tried to install ffmpeg through other means?
[00:17:41 CEST] <crst> pZombie: do you know jpegmini?
[00:18:03 CEST] <Bray90820> Illya: at this point you guess is as good as mine
[00:18:12 CEST] <pZombie> nope, only some other jpeg for video format
[00:18:32 CEST] <pZombie> is it worth knowing?
[00:18:45 CEST] <crst> http://beamr.com/jpegmini
[00:19:08 CEST] <Bray90820> Illya: http://pastebin.com/raw/YsRD8cZR
[00:19:31 CEST] <crst> this is the best reduction method i am aware of
[00:19:48 CEST] <pZombie> for photos, not videos i suppose
[00:19:57 CEST] <crst> They also made something for video
[00:20:16 CEST] <Ilya> Bray90820: and what was the error message when you ran ffmpeg again?
[00:20:16 CEST] <crst> but as a service only i think
[00:21:01 CEST] <Bray90820> Illya: http://pastebin.com/raw/CWnePQMj
[00:21:30 CEST] <pZombie> compressing static images vs compressing connected images where "stuff" is moving seems to be different tasks in quality i would think
[00:22:19 CEST] <pZombie> but certainly you would get a lot from just compressing the raw frames of a video with jpeg, ignoring motion altogether
[00:22:31 CEST] <pZombie> it just isn't the best way to compress videos i would think
[00:23:10 CEST] <pZombie> not like i know how h264 actually does it
[00:23:37 CEST] <crst> pZombie: that's right. I'm only thinking about the principle of max recution without a notice to the eye. Then you can save a lot without even thinking abaout quality compromise.
[00:23:39 CEST] <pZombie> i just assume that it considers motion, hence multiple connected frames for the compression, rather than single frames
[00:23:58 CEST] <Ilya> Bray90820: try uninstalling 'lame' and then reinstalling it with brew
[00:24:31 CEST] <Bray90820> uninstall it with rm?
[00:24:50 CEST] <Illya> just brew uninstall lame
[00:24:53 CEST] <Illya> and then brew install lame
[00:24:59 CEST] <pZombie> you can actually keep the output at the original format and get a high compression still while the output will look almost like the original
[00:25:32 CEST] <pZombie> crst - actually, let me test it. a quick encode without scaling. See what i get
[00:26:13 CEST] <pZombie> those are the time when you wish you had a 4k monitor
[00:26:38 CEST] <Bray90820> Illya: http://pastebin.com/raw/LwfSdRQ6
[00:26:42 CEST] <crst> pZombie: what are you testing exactly again?
[00:27:09 CEST] <Illya> Bray90820 I'd say try a force overwrite
[00:27:15 CEST] <pZombie> i am encoding the video with same settings as before, but without scaling it down to 720x405
[00:27:29 CEST] <pZombie> i will leave the size at 3840x2160 or whatever it was
[00:27:51 CEST] <Bray90820> Illya: Then what?
[00:27:58 CEST] <Illya> then try ffmpeg again
[00:29:27 CEST] <Illya> And if that still fails you could also try rebuild ffmpeg using: `brew uninstall ffmpeg` and then `brew install ffmpeg --HEAD`
[00:29:32 CEST] <crst> pZombie: I'm sorry I'm getting really tired unfortunately, half past 12am... what is the outcome to be expected?
[00:29:53 CEST] <Illya> which will clone ffmpeg from source and then build it on your machine as opposed to using the binaries provided
[00:29:59 CEST] <pZombie> i expect it to look like the original, indistinguishable
[00:30:08 CEST] <pZombie> the question is, how large it will be
[00:30:13 CEST] <Bray90820> Illya: Does it look good now?
[00:30:13 CEST] <Bray90820> http://pastebin.com/raw/W6n9iDCF
[00:30:29 CEST] <Illya> yes, that looks like it works now :)
[00:30:50 CEST] <Illya> seems to have been an error in symlinking lame properly
[00:31:01 CEST] <Illya> It generally Just Works"... I promise :)
[00:31:21 CEST] <Bray90820> Alright
[00:31:34 CEST] <crst> pZombie: ah I see. The question is, is it really undistinguishable like jpegmini does.
[00:32:37 CEST] <crst> like 100& undistunguishable
[00:32:44 CEST] <crst> *100%
[00:32:53 CEST] <pZombie> i think it is, recording of my screen with yuv444 were
[00:33:16 CEST] <pZombie> recordings*
[00:33:25 CEST] <Bray90820> Illya: Yes it papers to be copy the files correctly now
[00:34:11 CEST] <iml_> I hope this is not too much of a newbie question :-)
[00:34:28 CEST] <iml_> What would be the ffmpeg equivalent of "avconv -i input.ts -c copy output.mp4"
[00:34:37 CEST] <iml_> (This is a commandline that I have found here: https://superuser.com/a/520795 )
[00:34:47 CEST] <Bray90820> Illya: Now lets see if that code you gave me yesterday is actually what I want
[00:34:57 CEST] <t3v4> HI all :)
[00:35:24 CEST] <t3v4> Can anyone help me with use of ffmpeg's fft utilities? :)
[00:36:18 CEST] <hyponic> can ffmpeg transcode teletext subtitles to dvbsubtitles? anyone?
[00:36:23 CEST] <Illya> iml_: I think it would be: ffmpeg -i input.ts -c:a copy -c:v copy output.mp4
[00:36:25 CEST] <pZombie> crst - here is the recording of my screen with yuv444 https://drive.google.com/file/d/0BxMwFJfbOvWvUWhqRG16YzhVU0U/view  i did 1920x1080 so only part of the screen, in case someone uses a 1920x1080 monitor
[00:37:03 CEST] <Illya> t3v4: what's your question?
[00:37:05 CEST] <pZombie> crst you can see that even the small green fonts are accurate and pixel precise. Yet i did not record lossless, but with crf=20 only
[00:37:10 CEST] <pZombie> single pass
[00:38:46 CEST] <pZombie> the same done with 420 looks horrible
[00:39:17 CEST] <pZombie> so if you have good source material which has true 8bit per color or higher, 444 is the way to go
[00:39:20 CEST] <t3v4> I need to process audio signal, to convert it with fft
[00:39:28 CEST] <t3v4> But I found realfft
[00:39:32 CEST] <t3v4> and fft inside of ffmpeg
[00:39:43 CEST] <t3v4> What is difference and what is best for audio processing?
[00:39:47 CEST] <iml_>  Illya: Thanks! I'm testing it :-)
[00:40:38 CEST] <pZombie> this is actually taking longer now, without the scale, even though i used 16 threads. Already at 95mb size and rising
[00:41:17 CEST] <pZombie> i am getting the feeling that this might not even decode properly
[00:41:49 CEST] <crst> pZombie: wow, freaky stuff you're doing there. what do you do when you want to record for online presentation, i.e. youtube?
[00:42:04 CEST] <pZombie> haha speed = 0.0643
[00:42:08 CEST] <pZombie> that explains it
[00:42:31 CEST] <crst> with 420?
[00:42:34 CEST] <pZombie> 444
[00:42:48 CEST] <pZombie> so basically, this will take 40 minutes
[00:43:10 CEST] <pZombie> for a 2 min 22 sec video
[00:45:18 CEST] <crst> oh man this is really getting interesting, I'm too tired... I'm so sorry, I have to go to bed, can't even think properly anymore.
[00:45:40 CEST] <pZombie> lol, not really interesting
[00:45:42 CEST] <pZombie> something is fishy
[00:45:52 CEST] <pZombie> soon the output file will surpass the input
[00:46:08 CEST] <pZombie> oh wait
[00:46:11 CEST] <pZombie> this makes sense
[00:46:18 CEST] <pZombie> the input file was h265 haha
[00:46:23 CEST] <pZombie> omg i need some sleep too
[00:46:30 CEST] <crst> pZombie: lol
[00:46:45 CEST] <pZombie> take care :D
[00:46:47 CEST] <pZombie> gg bb
[00:47:39 CEST] <crst> you, too man, I think I'll be back tomorrow then we can get to the core of it
[00:48:00 CEST] <pZombie> yep, we'll figure it all out
[00:48:05 CEST] <pZombie> one day..
[00:48:16 CEST] <crst> :D
[00:48:24 CEST] <crst> cu
[00:49:10 CEST] <crst> bye guys and thanks a lot to everybody. it's really been nice!
[00:54:16 CEST] <Bray90820> Illya: doesn't loose audio or video quality right "ffmpeg -i Video.mkv -c:a copy Video.mp4"
[00:54:26 CEST] <Bray90820> The code you gave me
[00:56:23 CEST] <Illya> it will lose video quality
[00:56:26 CEST] <Illya> but not audio
[00:59:46 CEST] <Bray90820> Can I keep video and audio quality when converting?
[01:00:08 CEST] <Bray90820> Illya:
[01:02:39 CEST] <Illya> You can keep audio quality by not converting, you cannot keep the video quality though as you have lossless formats to begin with
[01:03:59 CEST] <Bray90820> I can't keep the same video quality as the original file?
[01:05:58 CEST] <Bray90820> How much loss is there?
[01:06:22 CEST] <Illya> Try it and see
[01:06:40 CEST] <Bray90820> There is no percentage?
[01:07:01 CEST] <Illya> Somewhere between 0% loss and 100% loss
[01:07:39 CEST] <Bray90820> That's not help
[01:07:44 CEST] <Bray90820> *no
[01:07:54 CEST] <Illya> That's because I dont know
[01:07:58 CEST] <Illya> no one knows
[01:08:05 CEST] <Illya> Like I said, try it and see.
[01:20:26 CEST] <pZombie> so what is the cheapest camera which can record 1920x1080 video in yuv444 rather than 420?
[01:22:28 CEST] <pZombie> i couldn't sleep, thinking that such a camera doesn't exist possibly
[01:25:41 CEST] <jkqxz> Recording in 444 is generally RGB instead.  (The sensors are all some Bayer pattern with interpolation anyway.)
[01:27:37 CEST] <pZombie> so there is no camera out there which can record true 8bit per color, compressed lossless(raw), video? Or did i misunderstand you?
[01:28:04 CEST] <pZombie> what does the interpolation do exactly?
[01:28:26 CEST] <jkqxz> (That is, your 4:4:4 output from a 1920x1080 sensor will have made up some of the colour information by interpolation, where a 4:2:0 output is closer to what it can actually see.)
[01:29:52 CEST] <pZombie> and why is all that? Are there physical limitations we have reached which do not allow us to record true 4:4:4?
[01:30:07 CEST] <pZombie> without any interpolation
[01:31:22 CEST] <jkqxz> What?  If you want more detail you use more pixels on the sensor.  The cameras all do a lot of postprocessing to turn their sensor input into the "raw" pixels you get, and with more information they can do a better job.
[01:31:48 CEST] <pZombie> i want accurate colors...
[01:32:10 CEST] <Illya> what's the point of more accurate colours if they cannot be seen?
[01:32:13 CEST] <pZombie> just as i see them in nature, i want them to be recorded 1:1, not some 4:2:0 crap
[01:32:38 CEST] <pZombie> then why do i see the difference between a screenrecording done in 444 and one done using 420?
[01:32:57 CEST] <pZombie> the colors are not accurate when using 420
[01:33:49 CEST] <jkqxz> Because screen captures can have 1-pixel-wide hard lines which you would never be able to capture on plausible camera.  It's not the same use at all.
[01:35:08 CEST] <pZombie> are you sure about that? What if i recorded my monitor with a high megapixel camera, the colors wouldn't look right when zooming in
[01:35:16 CEST] <jkqxz> A real camera actually dealing with light has enough blurring that it's very hard to see failing cases.  (Though indeed with contrived setups you can do that.)
[01:36:02 CEST] <Illya> pZombie: you dont want to accept that you're not correct, so you're dodging any point anyone makes. No one benefits from this conversation
[01:36:23 CEST] <jkqxz> If you recorded your monitor with a high megapixel camera you would see lots of weird coloured dots.  The blurring in your eyes makes it look like an image.  (Try looking at a monitor under a microscope sometime.)
[01:37:32 CEST] <pZombie> it's not that i am dodging. It just doesn't compute what he says. My example, recording the monitor with a high megapixel camera, zooming into the screen should show the problem. Especially the green colors won't be reproduced properly
[01:37:46 CEST] <jkqxz> You can already see the subpixel effects where hard lines have the red, green and blue at different offsets if you look closely at your monitor.
[01:38:13 CEST] <pZombie> ok, now we zoomed in too much
[01:38:42 CEST] <pZombie> sure, at some point we could see the electrons wizzing about
[01:39:24 CEST] <Illya> pZombie that's probably because your eyes are very good
[01:39:58 CEST] <pZombie> they are good at detecting colors
[01:40:02 CEST] <Illya> I like this post for giving it some sort of far fetched perspective, http://www.premiumbeat.com/blog/if-the-human-eye-was-a-camera-how-much-would-it-cost/
[01:40:09 CEST] <pZombie> color differences that is
[01:43:12 CEST] <jkqxz> The problem with this camera argument is that camers do /a lot/ of postprocessing, which messes with anything you might be trying to do.
[01:44:36 CEST] <jkqxz> If you got a camera with a 4K sensor, lined it up perfectly with a 1080p monitor so that every four Bayer pixels on the camera matched to one pixel on the monitor, then extracted the raw Bayer data from the sensor (some cameras do let you do this), then you could probably reconstruct exactly the image exactly as it was on the monitor modulo some sensor noise.
[01:44:40 CEST] <pZombie> i will record a video lossless with lagarith, then encode it using 444 and then 420, just to show you how great the differences in quality can be
[01:45:56 CEST] <jkqxz> (And if you did the same thing with a 1080p camera then you've already thrown away most of the colour information in the Bayer, so you might as well output 4:2:0 at the end of it because there isn't enough information to make anything better.)
[01:46:21 CEST] <Illya> 1920x1080 isnt that many pixels
[01:51:28 CEST] <pZombie> well, this is getting strange
[01:52:15 CEST] <pZombie> yuv444p does not give me the same 1:1 output which i get when recording with virtualdub, using vfwx264 and full color space input
[01:52:28 CEST] <pZombie> i must have messed something up with the command line
[01:55:09 CEST] <pZombie> i must have set something extra last time and forgot about it
[01:55:19 CEST] <pZombie> maybe the input color format or something like that
[02:18:16 CEST] <pZombie> do the x264 encoder settings get reseted each time you use ffmpeg, or is that an independent file? I cannot explain otherwise why i cannot reach the same quality anymore
[02:18:33 CEST] <pZombie> i must have unset something which is valid still even when i restart
[02:20:56 CEST] <DHE> ffmpeg reads its commandline and nothing else
[02:24:31 CEST] <pZombie> well, when i use x264vfw in virtualdub to capture, i can set "keep input colorspace", which then gives me 1:1 recordings or indistinguishable to the source. How do i set this within ffmpeg/x264?
[02:28:07 CEST] <pZombie> for the perfect quality file i recorded with vdub and x264vfw, i get following when using mediainfo
[02:28:08 CEST] <pZombie> Encoding settings                        : cabac=1 / ref=8 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=22 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 /
[02:28:08 CEST] <pZombie> b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
[02:28:23 CEST] <pZombie> how do i translate all this into ffmpeg?
[02:50:00 CEST] <pZombie> bloody hell, i had to use libx264rgb
[02:50:28 CEST] <pZombie> what is the difference between the two?
[02:54:31 CEST] <pZombie> never mind, quality isn't the same still as the vdub recording
[02:54:37 CEST] <pZombie> colors just a bit better
[03:43:55 CEST] <HiDeHo> hi all i have a video i am trying to rotate it 90deg to the right and save it so all players can use it. vlc failed.  i have wnff gui instaled and i get this error
[03:43:58 CEST] <HiDeHo> Unknown encoder 'libvo_aacenc'
[03:44:12 CEST] <HiDeHo> winff is a gui for avconv
[04:10:16 CEST] <jookiyaya> how come people don't use  xvid on mp4 container
[04:37:49 CEST] <yagiza> Hello!
[04:48:03 CEST] <yagiza> Do ffmpeg support SDP file which contain more than one payload type IDs in m= line?
[04:49:03 CEST] <yagiza> It seems to ignore all the IDs but first one.
[04:51:55 CEST] <hero100> yagiza, any sample?
[04:52:12 CEST] <yagiza> SDP:
[04:52:12 CEST] <yagiza> v=0
[04:52:12 CEST] <yagiza> o=- 0 0 IN IP4 127.0.0.1
[04:52:12 CEST] <yagiza> s=No Name
[04:52:12 CEST] <yagiza> c=IN IP4 127.0.0.1
[04:52:13 CEST] <yagiza> t=0 0
[04:52:13 CEST] <yagiza> a=tool:libavformat 57.26.100
[04:52:14 CEST] <yagiza> m=audio 6666 RTP/AVP 8 101
[04:52:14 CEST] <yagiza> b=AS:32
[04:52:15 CEST] <yagiza> a=rtpmap:101 iLBC/8000
[04:52:15 CEST] <yagiza> a=fmtp:101 mode=20
[04:53:41 CEST] <yagiza> hero100, now I'm streaming with iLBC/8000 encoder and payload type set to 101
[04:54:13 CEST] <yagiza> When m= line looks like this:
[04:54:13 CEST] <yagiza> m=audio 6666 RTP/AVP 101 9
[04:54:13 CEST] <yagiza> it play all right
[04:54:46 CEST] <yagiza> I mean
[04:54:46 CEST] <yagiza> m=audio 6666 RTP/AVP 101 8
[04:55:27 CEST] <yagiza> But when it is
[04:55:27 CEST] <yagiza> m=audio 6666 RTP/AVP 8 101
[04:55:27 CEST] <yagiza> it just hangs on
[04:55:27 CEST] <yagiza> avformat_find_stream_info()
[04:57:42 CEST] <hero100> I don't know if it's possible to set multiple fmt :       m=<media> <port> <proto> <fmt> ...
[04:58:57 CEST] <hero100> fmt higher than 96 is dynamic. fmt = 8 is PCMA
[05:02:08 CEST] <yagiza> hero100, I know
[05:39:17 CEST] <yagiza> hero100, RFC 4566 says:
[05:39:17 CEST] <yagiza> If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt>
[05:39:17 CEST] <yagiza>       sub-fields contain RTP payload type numbers.  When a list of
[05:39:17 CEST] <yagiza>       payload type numbers is given, this implies that all of these
[05:39:17 CEST] <yagiza>       payload formats MAY be used in the session, but the first of these
[05:39:18 CEST] <yagiza>       formats SHOULD be used as the default format for the session.
[05:41:20 CEST] <Bray90820> Does "ffmpeg -i Video.mkv -c:a copy Video.mp4" work with DTS Master and or Dolby True HD
[05:41:30 CEST] <yagiza> hero100, I don't know if that means that if payload type of the stream differs from the one, listed in m= line, we need to wait indefinitely before packed with specified payload type number arrives.
[05:42:10 CEST] <yagiza> "...differs, from the one, listed in m= line *first*..."
[05:43:55 CEST] <yagiza> So, the question is: how to get payload type number from the RTP packet?
[06:10:54 CEST] <ArboreSign> irc://irc.rizon.net/aegisub
[06:16:20 CEST] <hero100> yagiza, payload type number is included in RTP header.
[06:16:41 CEST] <hero100>    |V=2|P|X|  CC   |M|     PT      |       sequence number         |
[06:32:21 CEST] <yagiza> hero100, yes, but how can I tell FFMpeg to get it from the header?
[06:33:25 CEST] <yagiza> hero100, if I don't specify any payload type number at all, it just defaults it to zero instead of looking into RTP packets!
[06:42:42 CEST] <hero100> yagiza, I got it. And 'handle list of formats' is on the todo list.
[06:43:24 CEST] <yagiza> hero100, so, there's no solution right now?
[07:07:59 CEST] Action: yagiza wonders if it's the same shit in libav...
[09:53:44 CEST] <pZombie> how do you set the input color format for the encoder? NOT the output color format!
[09:54:51 CEST] <furq> it's autodetected from the input
[09:55:06 CEST] <furq> if it's being detected wrongly then set -pix_fmt before -i
[09:55:41 CEST] <pZombie> got you, let me test
[10:01:59 CEST] <pZombie> i am getting the error, option pixel_format not found when i set it before the -i
[10:03:54 CEST] <pZombie> ffmpeg.exe -pix_fmt bgra -i test.avi  -c:v libx264 -preset medium -crf 15   output.mp4    just gives this error
[10:05:46 CEST] <furq> https://www.ffmpeg.org/ffmpeg.html#Advanced-Video-options
[10:05:49 CEST] <furq> that should work fine
[10:18:41 CEST] <pZombie> is -crf <number> ignored completely?
[10:19:02 CEST] <furq> no?
[10:19:17 CEST] <pZombie> strange... does not seem to make a difference.
[10:20:02 CEST] <pZombie> i am preparing a few samples to show where my issue is. It should become obvious
[10:20:18 CEST] <mightymike> hi folks!
[10:20:40 CEST] <mightymike> I need help for decklink in ubuntu
[10:21:06 CEST] <mightymike> when I play with ffplay or ffmpeg the result is a black video
[10:29:24 CEST] <pZombie> let me begin with a screenshot of what i am trying to record, including the virtualdub settings i will be using in one of the samples, using x264vfw
[10:29:26 CEST] <pZombie> http://i.imgur.com/zk4kHSO.png
[10:30:34 CEST] <pZombie> here is the virtualdub x264vfw versions. https://drive.google.com/open?id=0BxMwFJfbOvWvUS1fNUp1ME5xRzQ
[10:30:48 CEST] <pZombie> it is the smallest in size and has the best quality out of the 3 samples i will present
[10:31:14 CEST] <pZombie> it looks pretty much identical to the lagarith lossless recording i used for the next 2 samples
[10:32:08 CEST] <pZombie> https://drive.google.com/open?id=0BxMwFJfbOvWvM09mZEsyakNvTDA   this is lagarith to h264 using libx264rgb. The colors are good, but the quality is horrible
[10:32:29 CEST] <pZombie> ffmpeg.exe -i lagarith.avi  -c:v libx264rgb -preset medium -crf 15   output.mp4 is what i used
[10:32:42 CEST] <pZombie> even lower crf than the vdub x264vwf settings
[10:32:50 CEST] <pZombie> file is larger, quality far worse
[10:33:11 CEST] <pZombie> https://drive.google.com/open?id=0BxMwFJfbOvWvblJ1bmg3NlRNVnc   this is using the standard libx264
[10:33:32 CEST] <pZombie> colors just plain wrong, as well as quality being horrible, yet the file size is larger
[10:33:47 CEST] <pZombie> ffmpeg.exe -i lagarith.avi  -c:v libx264 -preset medium -crf 15   output.mp4    what i used to encode it
[10:34:30 CEST] <pZombie> setting -pix_fmt yuv444 does not really make a difference, as this seems to apply only to the output format, or so it seems to me
[10:35:32 CEST] <pZombie> so how do i use ffmpeg to give me the same quality as x264vfw when using virtualdub?
[10:44:51 CEST] <pZombie> did anyone check the samples i uploaded???
[10:50:02 CEST] <pZombie> also, the original lagarith (104mb) file just finished uploading. https://drive.google.com/open?id=0BxMwFJfbOvWvME9UQkg1d09JbFk
[10:50:35 CEST] <pZombie> if anyone could download this and compress it with ffmpeg using libx264, then show the results, it would be greatly appreciated
[10:50:51 CEST] <pZombie> i need to see if it's just me, or if it's an issue with ffmpeg
[11:03:02 CEST] <pZombie> the problem seems to be the lagarith decoding within ffmpeg
[11:03:13 CEST] <pZombie> it does not seem to be lossless even though it should be
[11:03:49 CEST] <pZombie> i used some raw uncompressed avi and used libx264rgb, not the standard libx264, and got the perfect results
[11:35:36 CEST] <brontosaurusrex> pZombie: downloading.
[11:37:34 CEST] <pZombie> pointless i think. ffmpeg seems to not decode lagarith lossless
[11:37:57 CEST] <pZombie> when i used raw avi, and libx264rgb, i got the proper results
[11:43:21 CEST] <brontosaurusrex> pZombie: bitrates range from 3 to 10 mbits, so dunno how to compare this three.
[11:44:01 CEST] <pZombie> well, the smallest in size is also the best quality
[11:44:38 CEST] <pZombie> it looks exactly like the original lagarith 104mb file if you play it in a proper video recorded, which plays lagarith lossless as it should be
[11:45:14 CEST] <pZombie> now you could try to turn that lagarith into rawvideo, but it won't work using ffmpeg
[11:45:20 CEST] <pZombie> you would have to use something else
[11:45:54 CEST] <pZombie> then use the raw video and try to encode it perfectly as is the case for the smallest file of the three samples
[11:46:18 CEST] <pZombie> the default libx264 should not work for that, except you know some magic settings which would make it work
[11:46:46 CEST] <pZombie> the raw video fed into ffmpeg using libx264rgb seems to give proper results however
[11:48:24 CEST] <brontosaurusrex> so this one https://transfer.sh/Gl8k5/test.mp4 looks wrong as well?
[11:49:19 CEST] <brontosaurusrex> (ffmpeg -i lagarith.avi -vcodec libx264 -crf 21 -an test.mp4)
[11:49:27 CEST] <pZombie> of course it looks wrong. Did you open the 104mb lagarith lossless in a video player and compare?
[11:50:29 CEST] <pZombie> if it does not look exactly(or indistinguishable) from the 104mb lagarith lossless (played in a proper player with a proper lossless lagarith decoder) then it is not right
[11:50:59 CEST] <brontosaurusrex> define proper player (using mpv here)
[11:51:23 CEST] <pZombie> vlc with opengl renderer enabled or mpc-hc... don't know about mpv
[11:51:37 CEST] <pZombie> which OS are you using?
[11:51:44 CEST] <brontosaurusrex> debian
[11:52:26 CEST] <pZombie> then vlc would work i suppose, if you go to tools-> preferences -> video and set output to openGL, not automatic
[11:52:35 CEST] <pZombie> you have vlc installed?
[11:52:52 CEST] <brontosaurusrex> yes
[11:53:35 CEST] <pZombie> you can use this screenshot to compare http://i.imgur.com/zk4kHSO.png
[11:53:52 CEST] <pZombie> if the colors do not look exactly like this, then the lagarith is not playing back properly
[11:54:00 CEST] <brontosaurusrex> I think mp4 version is slightly more blue, but really just slightly.
[11:54:23 CEST] <pZombie> the green is the most important
[11:54:36 CEST] <pZombie> it looks plain wrong on the mp4 versions
[11:54:51 CEST] <pZombie> you cannot discern the small fonts in green either
[11:55:33 CEST] <pZombie> does vlc play the lagarith 104mb video with the same color reproduction as in the screenshot i showed you?
[11:55:46 CEST] <brontosaurusrex> pZombie: dunno
[11:55:52 CEST] <pZombie> ?
[11:56:01 CEST] <pZombie> how can you not know? Are you color blind?
[11:56:32 CEST] <brontosaurusrex> All the men are slightly color-blind, are you female?
[11:56:45 CEST] <pZombie> no, but i have perfect color recognition
[11:57:06 CEST] <pZombie> can you make a screenshot of vlc playing the lagarith video?
[11:57:14 CEST] <brontosaurusrex> sure
[11:57:16 CEST] <pZombie> great
[11:57:39 CEST] <pZombie> upload it in lossless png if possible
[11:57:48 CEST] <pZombie> cut only the part where it shows playing in vlc
[11:58:04 CEST] <pZombie> if the file gets too big, imgur will turn it into jpeg
[11:58:58 CEST] <brontosaurusrex> https://transfer.sh/OVHI7/stupidvlc.png
[12:00:23 CEST] <pZombie> something is not right with your player
[12:00:36 CEST] <pZombie> maybe it cannot decode lagarith properly
[12:00:47 CEST] <pZombie> it looks messed up
[12:01:01 CEST] <pZombie> the colors are produced ok though
[12:01:06 CEST] <brontosaurusrex> Perhaps you should use some other mezazine codec?
[12:01:23 CEST] <brontosaurusrex> I always had problems with lagarith in the past
[12:02:03 CEST] <pZombie> can you run the x264vfw_vdub.avi and take a screenshot of that too?
[12:02:10 CEST] <pZombie> that is the best quality sample
[12:02:11 CEST] <brontosaurusrex> pZombie: ok
[12:02:28 CEST] <pZombie> maybe it plays properly in the player
[12:04:01 CEST] <pZombie> linux could really use some players which play the input perfectly by default, without having to mess around for hours
[12:04:16 CEST] <pZombie> like mpc-hc does for windows
[12:05:37 CEST] <brontosaurusrex> https://transfer.sh/h8vIO/vlcandmpv.png < vlc top, mpv bottom (indeed vlc is borken, that is why I dont ever use it i guess)
[12:06:57 CEST] <pZombie> the bottom one looks somewhat correct, not perfect though
[12:07:11 CEST] <pZombie> the small fonts are a bit messed up on the right diagram
[12:07:44 CEST] <pZombie> did you pause the video before taking the screenshot?
[12:08:44 CEST] <brontosaurusrex> Actually it looks like vlc is skiping a faze or two, mpv is too soft thought.
[12:08:54 CEST] <brontosaurusrex> yes, both paused
[12:10:51 CEST] <pZombie> either way, the colors are not reproduced properly, but not too far from the original
[12:11:05 CEST] <Lirk> Can I use ffmpeg as rtmp server?
[12:11:30 CEST] <Lirk> not only encoder but also as listening rtmp-server>
[12:11:32 CEST] <Lirk> ?
[12:11:34 CEST] <pZombie> and your vlc output looks blurred, not sure if that is the correct term for this
[12:11:43 CEST] <brontosaurusrex> how does the h.264 deblocking faze works with 4:4:4? < is probably the question + all the color erros
[12:12:11 CEST] <brontosaurusrex> pZombie: I never use vlc, so i never bothered to do any configs.
[12:12:30 CEST] <brontosaurusrex> so could be just some missconfig ....
[12:13:17 CEST] <pZombie> i made another screenshot i just captured http://i.imgur.com/KB8HSzs.png
[12:13:38 CEST] <pZombie> the small numbers can look messy if you pause the wrong time however, that is true for me as well
[12:14:03 CEST] <pZombie> but my output is more vivid and very close if not identical to the original
[12:14:24 CEST] <brontosaurusrex> pZombie: that does look proper (ignoring the colors)
[12:15:41 CEST] <pZombie> most users do not bother, because they believe that their output is just as it should be
[12:15:44 CEST] <Lirk_> Can I use ffmpeg as rtmp server?
[12:15:48 CEST] <pZombie> how should they know anyway?
[12:16:17 CEST] <pZombie> the default windows player is horrible as well depending on the input
[12:16:30 CEST] <pZombie> vlc needs tweaking on windows as well for the proper output
[12:17:02 CEST] <pZombie> mpc-hc is the only player i tested so far which gives proper reproduction of the material at default settings
[12:17:10 CEST] <pZombie> there are probably more out there i did not try
[12:17:29 CEST] <pZombie> unfortunately it does not exist for linux i believe
[12:20:46 CEST] <pZombie> brontosaurusrex, i was thinking about your comment of all men being a little bit color blind. Maybe this explains why there are so many problems with the codecs :D
[12:21:05 CEST] <pZombie> like lagarith which is a lossless format, not being decompressed lossless in ffmpeg
[12:21:17 CEST] <pZombie> which makes using lagarith pointless in ffmpeg
[12:22:07 CEST] <pZombie> a shame, because it is one of the few lossless formats i can record 2560x1440 video of my screen at about 60 fps
[12:22:30 CEST] <brontosaurusrex> pZombie: and UT video?
[12:22:40 CEST] <pZombie> does ffmpeg support ut video?
[12:22:44 CEST] <brontosaurusrex> yes
[12:22:50 CEST] <pZombie> i have to try that one
[12:23:51 CEST] <brontosaurusrex> x264 also has a lossless option
[12:24:34 CEST] <pZombie> yes, but even if you get it to work, which you probably won't with ffmpeg, it never is truly lossless or so i have read
[12:24:51 CEST] <pZombie> whereas lagarith and ut video are truly lossless
[12:28:03 CEST] <pZombie> lagarith is much faster
[12:28:09 CEST] <pZombie> or so it seems in my initial tests
[12:30:00 CEST] <pZombie> i do manage 2560x1440 @ 30 fps though with ut, but since it barely manages 45 max, the stability is not exactly the best
[12:30:27 CEST] <pZombie> lagarith can go up to 75 fps at max on my system, so capturing at 30fps is very stable
[12:41:23 CEST] <pZombie> brontosaurusrex, you are right, ut is well supported in ffmpeg it seems
[12:41:34 CEST] <pZombie> using ffmpeg.exe -i test.avi  -c:v libx264rgb -preset fast -crf 20   -pix_fmt yuv444p output.mp4   (not libx264) the output is perfect
[12:42:02 CEST] <pZombie> too bad it isn't a little bit faster
[12:42:39 CEST] <brontosaurusrex> so if x264 is lossless it should return the same hash right?
[12:43:28 CEST] <pZombie> that's too deep for me, but it sounds about right
[12:43:50 CEST] <pZombie> i doubt you can get lossless using libx264 however, unless there are some magical settings i don't know about
[12:44:02 CEST] <pZombie> using libx264rgb in ffmpeg it seems very much possible
[12:44:17 CEST] <brontosaurusrex> ffmpeg -i lagarith.avi -pix_fmt rgb24 -vcodec libx264rgb -qp 0 -preset veryslow lossless.mp4 < this should work, but it isnt
[12:44:42 CEST] <pZombie> no, forget about lagarith
[12:44:43 CEST] <brontosaurusrex> hash is different than that of the lagarith sample
[12:45:07 CEST] <pZombie> you cannot use lagarith in ffmpeg, it does not treat it as lossless, again, unless there are some magical settings i do not know about
[12:45:08 CEST] <brontosaurusrex> yeah, could be a lagarith decoder problem of some sort
[12:45:17 CEST] <brontosaurusrex> right.
[12:48:04 CEST] <furq> brontosaurusrex: if you're doing a framehash test then you might need to explicitly pass -pix_fmt
[12:48:20 CEST] <furq> e.g. rgba and bgra will have different hashes in spite of being effectively identical
[12:48:33 CEST] <brontosaurusrex> furq: let me try
[12:50:55 CEST] <brontosaurusrex> furq: pZombie: spot on: http://paste.debian.net/plain/740270
[12:51:23 CEST] <furq> yeah i think x264 uses bgr24
[12:51:30 CEST] <furq> i've never had cause to use it though
[12:51:46 CEST] <brontosaurusrex> so x264 IS lossless! lol
[12:51:49 CEST] <furq> it sure is
[12:52:07 CEST] <pZombie> interesting
[12:52:55 CEST] <pZombie> brontosaurusrex, did you use libx264rgb or libx264?
[12:53:27 CEST] <brontosaurusrex> pZombie: the rgb one
[12:54:01 CEST] <pZombie> damn it works
[12:54:37 CEST] <pZombie> ffmpeg.exe -i lagarith.avi  -c:v libx264rgb -pix_fmt rgb24 output.mp4  gives me the perfect output
[12:54:42 CEST] <furq> correction: it uses gbrp
[12:55:06 CEST] <furq> which is good, i was worried it was using a packed format
[12:56:00 CEST] <pZombie> well done brontosaurusrex
[12:56:07 CEST] <pZombie> brontosaurusrex++
[12:56:21 CEST] <brontosaurusrex> pZombie: so besides x264 possibility of beging lossless we solved your color problems as well?
[12:56:30 CEST] <brontosaurusrex> yeah iam good! ;)
[12:56:57 CEST] <brontosaurusrex> actually furq is, but lets not talk about that.
[12:57:09 CEST] <furq> i like to keep my donations anonymous
[12:57:16 CEST] <pZombie> yes, colors are perfect, output looks 1:1 to original but is 1/10th of the size of the lagarith avi which in turn is a fraction of the size of raw video
[12:58:56 CEST] <furq> i don't think -pix_fmt rgb24 is actually doing anything there
[12:59:02 CEST] <furq> afaik libx264rgb always outputs gbrp
[12:59:44 CEST] <pZombie> yes, it works without just as well
[13:00:04 CEST] <pZombie> the question is, why my initial tests failed when using libx264rgb and lagarith
[13:00:10 CEST] <pZombie> i must have messed something up
[13:01:16 CEST] <brontosaurusrex> the question is mostly why rgb to yuv conversion is so visually lossy?
[13:01:39 CEST] <furq> rgb to yuv444p shouldn't be lossy
[13:02:13 CEST] <furq> 420p will look bad in pathological cases like screen capturing coloured text
[13:02:34 CEST] <furq> or youtube videos whose authors don't know that you need to put a black outline around text overlays
[13:03:06 CEST] <brontosaurusrex> i mean rgb to yuv444 seems to be lossy, otherwise pZombie wouldnt notice a problem.
[13:03:16 CEST] <brontosaurusrex> or there is another problem.
[13:04:13 CEST] <brontosaurusrex> right it shoudnt be
[13:06:11 CEST] <pZombie> brontosaurusrex, i think you are onto something here, but i lack the deep insight about how x264 works under the hood to make an educated guess
[13:06:39 CEST] <pZombie> it seems that a lot more details are lost than should when going 420p
[13:06:39 CEST] <brontosaurusrex> pZombie: same here + I don't know enough anout ffmpeg.
[13:07:17 CEST] <brontosaurusrex> pZombie: why 420? All your encodes are 444 yuv.
[13:07:39 CEST] <brontosaurusrex> The ones you posted at the beginning i mean.
[13:07:42 CEST] <pZombie> yes, but it looks the same bad
[13:07:52 CEST] <brontosaurusrex> right
[13:08:12 CEST] <furq> i'd expect 420 to look like garbage for your use case
[13:08:17 CEST] <furq> but 444 should look pretty much the same
[13:08:25 CEST] <pZombie> well, it doesn't
[13:08:37 CEST] <furq> i take it you've tested with multiple players
[13:08:45 CEST] <pZombie> yes
[13:09:11 CEST] <pZombie> my players are setup to keep the output as close to the input as possible
[13:10:42 CEST] <brontosaurusrex> well yuv444 is not lossless, at least not on the has level.
[13:10:47 CEST] <brontosaurusrex> hash*
[13:11:43 CEST] <furq> i can't remember off hand whether rgb -> yuv -> rgb is lossless
[13:12:36 CEST] <furq> but if it's not then you'd only notice that as slightly washed-out colours
[13:12:37 CEST] <brontosaurusrex> furq: right, but it should be at least near lossless, right? I mean it should be not noticable to human being?
[13:12:39 CEST] <furq> it wouldn't be blocky
[13:14:54 CEST] <pZombie> i must have had my player setting messed up when doing experiments earlier, and when playing back this sample lagarith_toh264_using_libx264rgb_ffmpeg.mp4
[13:15:14 CEST] <pZombie> because this one looks identical to the good recording using vdub x264vfw_vdub.avi
[13:15:29 CEST] <pZombie> however, the vdub recording is less than half the size
[13:15:36 CEST] <furq> take screenshots with ffmpeg if you want to make sure it's not the player
[13:15:54 CEST] <furq> ffmpeg -ss 30 -i foo.mp4 bar.png
[13:16:13 CEST] <pZombie> what does -ss 30 do?
[13:16:24 CEST] <furq> er
[13:16:28 CEST] <furq> ffmpeg -ss 30 -i foo.mp4 -frames:v 1 bar.png
[13:16:32 CEST] <furq> -ss 30 seeks to 30 seconds
[13:17:16 CEST] <pZombie> brontosaurusrex, with virtualdub + 264xvfw i can record lossless at half the size or less
[13:17:21 CEST] <brontosaurusrex> That makes a lot of sense.
[13:17:49 CEST] <brontosaurusrex> pZombie: good, so it is fast enough for your uhd 60 fps?
[13:17:57 CEST] <furq> didn't you encode one with a lower crf because you thought it looked bad
[13:19:12 CEST] <pZombie> i will do following now, set only crf=20 for both the ffmpeg libx264rgb and 264xvfw inside vdub, then encode the lagarith.avi with those settings
[13:19:51 CEST] <pZombie> the libx264rgb will be identical in quality to the x264vfw output, but the x264vfw will be less than half the size
[13:19:57 CEST] <pZombie> or so i believe
[13:20:02 CEST] <pZombie> let me try again
[13:20:44 CEST] <pZombie> ffmpeg.exe -i lagarith.avi  -c:v libx264rgb -crf 20  output.mp4   this is what i used
[13:21:09 CEST] <pZombie> seems i was wrong, size is 14,979,150
[13:21:22 CEST] <pZombie> so yes, i used a lower crf before maybe
[13:21:36 CEST] <pZombie> quality is good, perfect still
[13:22:41 CEST] <pZombie> what is the default preset for ffmpeg if you do not set anything? slower?
[13:23:52 CEST] <pZombie> well, i set it to slower now
[13:23:58 CEST] <furq> medium
[13:24:03 CEST] <pZombie> so it is equal to the one in x264vfw
[13:24:40 CEST] <pZombie> almost identical file sizes
[13:26:12 CEST] <pZombie> furq - Can you explain what the difference is between libx264 and libx264rgb when encoding and why i (personally) notice such a huge quality difference?
[13:33:43 CEST] <pZombie> mediainfo gives me Color range  : Full for my vdub recording, whereas color range  is limited with my ffmpeg libx264rgb recording
[13:33:48 CEST] <pZombie> what is the difference ?
[13:43:13 CEST] <Regda> how can i multiply an stream over another using tblend filter ? or does i need to use another one ?
[13:45:05 CEST] <brontosaurusrex> pZombie: not sure, but googling "ffmpeg rgb to yuv and color range" gives lots of hits.
[13:46:07 CEST] <pZombie> ffmpeg.exe -i lagarith.avi  -c:v libx264rgb -preset slower -crf 20 -color_range 2 output.mp4   with this, i managed to get color range: full in mediainfo
[13:46:24 CEST] <pZombie> but i am not sure if this is something which improves quality
[13:46:34 CEST] <Regda> (nah sry, i used tblend instead of blend....)
[13:46:38 CEST] <pZombie> maybe it needs some special case recording to see the difference
[14:07:52 CEST] <Regda> is it possible to use an stream multiple times instead of splitting them ?
[14:15:07 CEST] <tomato> is there any good way of getting the max bitrate of an audio file?
[14:15:18 CEST] <tomato> it's a cbr so the bitrate varies
[14:15:29 CEST] <furq> cbr is constant bitrate
[14:15:31 CEST] <tomato> ffprobe gives me an average bitrate which isn't accurate
[14:15:34 CEST] <tomato> *vbr
[14:15:37 CEST] <tomato> sorry meant vbr
[14:16:00 CEST] <furq> some codecs allow you to set -b:a to cap the bitrate, but i don't think that works for any audio codecs
[14:16:32 CEST] <tomato> I need to get the max bitrate of the audio
[14:16:41 CEST] <furq> oh sorry, i thought you said set
[14:16:44 CEST] <furq> try mediainfo i guess
[14:16:49 CEST] <tomato> tried that too
[14:16:52 CEST] <tomato> gives same info as ffprobe
[14:17:12 CEST] <tomato> it gives me a bitrate which I think is the average
[14:17:20 CEST] <tomato> not entirely sure how it's calculated
[14:17:26 CEST] <furq> i get average and maximum bitrate from mediainfo
[14:17:48 CEST] <tomato> on a vbr?
[14:19:01 CEST] <furq> yeah
[14:19:11 CEST] <furq> maybe it depends on the codec/container
[14:20:06 CEST] <tomato> yeah I think that's the case
[14:20:17 CEST] <tomato> I just get the overall bit rate
[14:23:18 CEST] <brontosaurusrex> I guess the file would have to be parsed to get the max/min bitrate somehow
[14:23:38 CEST] <brontosaurusrex> and mediainfo is just metadata reader afaik
[14:23:47 CEST] <tomato> yeah exactly
[14:23:55 CEST] <tomato> it'll be too slow to go through the entire file
[14:24:33 CEST] <pZombie> doesn't it depend on the encoder or even software applying the encoder? Maybe it writes the max bitrate somewhere at a place reserved for this info in the appropriate container
[14:24:47 CEST] <pZombie> maybe some containers have such reserved space for this info, while others don't
[14:25:02 CEST] <pZombie> maybe some encoders or encoder software makes use of this reserved space, while others don't
[14:26:07 CEST] <pZombie> mediainfo certainly does not parse the whole audio to get this info
[14:26:19 CEST] <pZombie> it just checks for some reserved space for this info
[14:26:22 CEST] <tomato> mediainfo just checks the meta as far as I know
[14:26:59 CEST] <tomato> I'm pretty sure it's the encoder that tracks down the info and adds it to the meta while it's processing the data
[14:27:10 CEST] <brontosaurusrex> there are some fields there http://paste.debian.net/740287/ (mediainfo --Info-parameters | grep -i bitrate)
[14:48:26 CEST] <jookiyaya> x264 core 142 r2453 ea0ca51
[14:48:26 CEST] <jookiyaya> Encoding settings              : cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 /
[14:48:26 CEST] <jookiyaya> bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=400 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
[14:50:55 CEST] <Regda> pastebin is under heavy load x/
[14:51:58 CEST] <pZombie> anyone tried some vp9 encoding and managed to play it back?
[14:52:21 CEST] <pZombie> my last attempt to encode seemed to have worked, but it did not play with any player i tried
[15:18:13 CEST] <Regda> pZombie: since version 2.2.0 VLC supports vp9 too
[15:19:00 CEST] <pZombie> i am looking at https://trac.ffmpeg.org/wiki/Encode/VP9 right now. Maybe i did not use the proper container
[15:19:04 CEST] <pZombie> they use .webm
[15:20:25 CEST] <Regda> uhm why not webm ?
[15:20:47 CEST] <pZombie> well, i didn't know. I am no expert on containers
[15:20:54 CEST] <pZombie> i just used avi for my test
[15:21:07 CEST] <Regda> try mp4 or webm
[15:21:13 CEST] <pZombie> encoding something now with .webm as container, see what i get
[15:21:18 CEST] <furq> don't use mp4
[15:21:23 CEST] <pZombie> encoding times are really slow
[15:21:32 CEST] <Regda> why not ?
[15:21:35 CEST] <hanshenrik> i want to copy video stream 1:0 and audio stream 1:2 and subtitle stream 1:3... how do i do that?
[15:21:38 CEST] <furq> because vp9 isn't supported in webm
[15:21:39 CEST] <pZombie> like 0.1x on a 5960x
[15:21:45 CEST] <furq> and yeah libvpx is really slow
[15:21:53 CEST] <furq> there's not much you can do about it
[15:22:30 CEST] <Regda> ah ok :/
[15:22:43 CEST] <furq> hanshenrik: -c copy -map 1:0 -map 1:2 -map 1:3
[15:23:01 CEST] <hanshenrik> thank you furq
[15:23:29 CEST] <Regda> i have an problem with character escaping inside an batch: http://pastebin.com/3E8f7V2b
[15:24:29 CEST] <Regda> i get an unknown error, but if i dont use variables and paste the command into the cmd then it works.
[15:26:11 CEST] <Regda> can someone take a look on it ? (i think that i forgot somthing)
[15:30:13 CEST] <hanshenrik> is ffmpeg fsync()'ing or something during conversion?
[15:30:14 CEST] <hanshenrik> or fopen with O_SYNC or somthin?
[15:31:59 CEST] <hanshenrik> (more likely scenario: don't trust the microsoft OS fs cache)
[15:33:16 CEST] <JEEB> you can look at the AVIO implementation of file
[15:33:21 CEST] <JEEB> what it does on different OSs
[15:33:39 CEST] <JEEB> (and toolchains)
[15:37:44 CEST] <Regda> bah
[15:47:43 CEST] <brontosaurusrex> pZombie: vp9 is slow and bitrate is all over the place (is my experience)
[15:48:28 CEST] <furq> libvpx is slow
[15:48:37 CEST] <brontosaurusrex> pZombie: I used "-c:v libvpx-vp9 -crf 21 -threads 16 -speed 2 -tile-columns 6 -frame-parallel 1 -b:v 0"
[15:48:39 CEST] <furq> there's at least one faster vp9 encoder but it's commercial
[15:48:53 CEST] <furq> and yeah it's slice-based multithreading and iirc the minimum slice size is 512px wide
[15:49:05 CEST] <furq> so unless your video is >1024 wide then you're using one thread
[15:49:44 CEST] <furq> it's not that slow compared to x264 using sliced multithreading, but nobody uses that because it sucks
[15:49:47 CEST] <furq> except for realtime
[15:56:07 CEST] <pZombie> brontosaurusrex, roger that. I tried different settings but for whatever reason it would not show in vlc, just black screen
[15:56:33 CEST] <pZombie> tried makewebm after and it worked, but the result was laughable in quality
[15:56:45 CEST] <pZombie> trying some different settings now
[15:57:29 CEST] <pZombie> it's bugged too
[16:01:52 CEST] <pZombie> wow, this is bad
[16:02:05 CEST] <pZombie> i thought vp9 was supposed to compete vs h265
[16:02:35 CEST] <pZombie> either the decoders don't work well or i am not setting the encoder up properly
[16:02:47 CEST] <pZombie> or it's just a bad quality encoder
[16:05:00 CEST] <brontosaurusrex> furq: example cli for sliced multithreading?
[16:06:08 CEST] <pZombie> brontosaurusrex, how was the quality of the produced video you got from it?
[16:06:35 CEST] <pZombie> i am trying your settings now, see what i get
[16:07:14 CEST] <warsh> hello. Might be a bit of a vague question, but is there a general idea of recommended hardware to help with transcoding video to the webm format with VP9 ?
[16:07:16 CEST] <pZombie> same as before. Video does not play at all in VLC
[16:07:38 CEST] <pZombie> black screen, yet it does play the videos produced with makewebm
[16:07:56 CEST] <furq> brontosaurusrex: iirc that's what tile-columns does
[16:08:19 CEST] <pZombie> brontosaurusrex, does your video play?
[16:09:31 CEST] <pZombie> warsh before you spend any money, i would first test if you can get any working videos at all with the current ways to encode it
[16:10:10 CEST] <warsh> with my 3770k I get a speed of 0.206x
[16:10:12 CEST] <furq> are there any non-specialist vp9 hardware encoders yet
[16:10:45 CEST] <pZombie> i can get it up to speed 0.6x with the proper settings like -speed 4
[16:10:57 CEST] <furq> -speed 4 reduces quality
[16:11:02 CEST] <warsh> hmm
[16:11:12 CEST] <pZombie> yes, but it's good for testing purposes i guess
[16:11:13 CEST] <warsh> gotta love a lossless conversion
[16:11:18 CEST] <BtbN> I think Kaby Lake will have a VP9 hardware encoder.
[16:11:24 CEST] <pZombie> i cannot even produce a working vp9 video with ffmpeg
[16:11:43 CEST] <furq> BtbN: do you know if amd/nvidia have announced any support for it
[16:11:51 CEST] <BtbN> They didn't.
[16:11:54 CEST] <BtbN> Only for decoding.
[16:11:58 CEST] <furq> shame
[16:12:11 CEST] <BtbN> VP9 isn't exactly well specified.
[16:13:45 CEST] <warsh> hmm
[16:14:02 CEST] <furq> brontosaurusrex: https://groups.google.com/a/webmproject.org/d/msg/codec-devel/IFFSy2xlKV0/iaYMn21BA5cJ
[16:14:08 CEST] <furq> -t is the vpxenc equivalent of -threads
[16:15:01 CEST] <brontosaurusrex> furq: right
[16:15:17 CEST] <furq> i'm not sure where i got 512 from
[16:15:20 CEST] <brontosaurusrex> pZombie: the quality was fine, but worse than x264 every time
[16:15:27 CEST] <brontosaurusrex> pZombie: + a lot slower
[16:15:35 CEST] <pZombie> so it plays for you, nice
[16:15:45 CEST] <furq> and yeah vp9 works fine for me in mpc-hc and mpv
[16:15:49 CEST] <BtbN> x264 is just extremely good at its job.
[16:15:51 CEST] <pZombie> maybe i should try some other ffmpeg. Not the one i compiled myself
[16:15:52 CEST] <furq> and in firefox for that matter
[16:16:09 CEST] <furq> brontosaurusrex: i'd expect vp9 to win if you use -speed 1 and a low crf
[16:16:13 CEST] <furq> but it'll be even slower than stock
[16:16:35 CEST] <furq> there's no point using it over hevc if you don't need browser support
[16:16:49 CEST] <furq> and i don't really think there's that much point using hevc over avc yet
[16:19:12 CEST] <brontosaurusrex> furq: right, even browser support isnt that good (compared to h264)
[16:19:22 CEST] <brontosaurusrex> furq: my latest notes were short http://brontosaurusrex.github.io/2016/05/04/vp9-encoding/
[16:20:05 CEST] <furq> your ascii art needs more box drawing characters
[16:21:02 CEST] <brontosaurusrex> "box drawing?" ingluoso is not my first language btw.
[16:21:21 CEST] Action: warsh clicks
[16:21:24 CEST] <viric> :)
[16:21:39 CEST] <furq> https://en.wikipedia.org/wiki/Box-drawing_character
[16:21:46 CEST] <furq> although i actually meant https://en.wikipedia.org/wiki/Block_Elements
[16:21:50 CEST] <viric> libcaca has parameters.
[16:21:56 CEST] <furq> i thought the former encompassed the latter, but it doesn't
[16:21:59 CEST] <viric> to use broad character sets
[16:22:33 CEST] <furq> it always weirds me out when people use 8 for shading instead of ’
[16:22:54 CEST] <brontosaurusrex> :)
[16:23:41 CEST] <viric> img2txt -f FORMAT
[16:23:42 CEST] <Denis___> Hello guys! Could anyone help me with avformat_alloc_output_context2 error -22 (Invalid argument), please?
[16:23:50 CEST] <warsh> brontosaurusrex: what kind of speed do you get when you encode with a constant quality
[16:23:58 CEST] <viric>                         ansi: ANSI
[16:23:58 CEST] <viric>                         utf8: UTF-8 with ANSI escape codes
[16:24:06 CEST] <brontosaurusrex> warsh: with vp9?
[16:24:16 CEST] <warsh> "ffmpeg -i input.mp4 -c:v libvpx-vp9 -crf 10 -b:v 0 -c:a libvorbis output.webm"
[16:24:18 CEST] <warsh> specifically
[16:25:24 CEST] <furq> warsh: you probably want to set -tile-columns and -threads to enable multithreading
[16:25:31 CEST] <brontosaurusrex> warsh: On the machine i'am currently isprobably not worth even trying, getting 5fps with x.264 -preset fast ...
[16:25:56 CEST] <furq> nice
[16:25:56 CEST] <brontosaurusrex> is= on is
[16:26:01 CEST] <furq> i'm pretty sure my rpi is faster than that
[16:26:06 CEST] <viric> by the way, these h264 encoders like nvenc and vaapi... they don't get as much quality as x264 *by far*, isn't it?
[16:26:18 CEST] <pZombie> ffplay plays the video, but vlc does not
[16:26:19 CEST] <furq> yeah consumer hardware encoders are pretty bad quality
[16:26:34 CEST] <pZombie> yet vlc plays the video generated with makewebm
[16:26:35 CEST] <viric> furq: thank you. Even decoders, I'd say. :)
[16:26:47 CEST] <brontosaurusrex> older i5 of some sort:  Dual core Intel Core i5 650 (-HT-MCP-) cache: 4096 KB
[16:26:51 CEST] <furq> i'm pretty sure nvenc is specifically aiming to be on par with x264 ultrafast
[16:27:01 CEST] <viric> furq: I noticed that reencoding h264 goes much worse, depending whether I decode by vaapi or by software
[16:27:03 CEST] <pZombie> either case, the quality is so bad
[16:27:03 CEST] <spooooon> Anyone have experience depacketizing MJPEG? I'm having zero fun trying to do it myself
[16:27:12 CEST] <viric> furq: ah ok, good to know
[16:27:17 CEST] <furq> since it's mostly targeted at livestreaming
[16:27:25 CEST] <viric> also vaapi, isn't it?
[16:27:30 CEST] <viric> (targeted at live streaming)
[16:27:40 CEST] <furq> yeah, and vce or whatever amd's one is called that nobody uses
[16:27:49 CEST] <viric> well, nvenc full hd does ~100fps here, in a cheap recent card
[16:28:07 CEST] <viric> furq: I thought ati/amd were using vaapi too. I meant intel, in my case
[16:28:07 CEST] <brontosaurusrex> actually getting 8fps with x.264 fast (and that is with yadif and -tune film as well)
[16:28:11 CEST] <warsh> brontosaurusrex: what kinda setup would improve performance, more cores, high clock speed, applying black magic to push the job to the gpus
[16:28:20 CEST] <furq> warsh: for vpx, clock speed
[16:28:27 CEST] <furq> vpx's multithreading is really weak
[16:28:32 CEST] <brontosaurusrex> warsh: for vp9 only multiple encodes at once imho
[16:28:35 CEST] <warsh> hmm
[16:29:15 CEST] <viric> Does anybody know a software TBC (to fix vhs already-digitized videos)
[16:29:16 CEST] <viric> ?
[16:29:33 CEST] <pZombie> warsh you could always pay almost 2k for just the CPU and get a 10 core i7-6950, then overclock the hell out of it with the hugest water cooler heatsink you can get
[16:29:50 CEST] <warsh> pZombie: why not NO2, heh
[16:29:53 CEST] <furq> 10 cores is basically useless for vp9 unless you're transcoding 4k
[16:30:08 CEST] <warsh> some of the older amd processors clock pretty high
[16:30:15 CEST] <warsh> s/clock/overclock
[16:30:25 CEST] <furq> yeah but pentium 4s clock pretty high as well
[16:30:30 CEST] <pZombie> yes, but high clock on AMD does not mean more performance than a lower clocked intel cpu
[16:30:42 CEST] <furq> clock rates alone don't mean much
[16:30:49 CEST] <jkqxz> VAAPI will give you >200fps transcode at 1080p of H.264, H.265 or VP8 on any recent Intel.  I assume that will also be true for Kaby Lake VP9, though I imagine the quality will be rather dodgy.
[16:31:01 CEST] <furq> the newest rpi is a 1.5ghz quad core but somehow i don't think it'll be half as fast as a 3ghz i5
[16:31:22 CEST] <viric> jkqxz: my recent cheap notebook does 60fps in h264, quite poor
[16:32:07 CEST] <viric> I don't know why vaapi/nvenc target anything more than 25 or 50fps
[16:32:16 CEST] <brontosaurusrex> viric: search doom9 forums
[16:32:17 CEST] <viric> they could just improve the encoder, once they reach 50fps
[16:32:27 CEST] <pZombie> if you don't want to pay too much, a i7-6700k overclocked is your best bet
[16:32:34 CEST] <furq> warsh: if you're encoding enough vp9 that you're prepared to spend money on it, there are commercial encoders available
[16:32:41 CEST] <jkqxz> Well, it's more for doing 10 streams of 1080p30 rather than 1 stream of 1080p200.
[16:32:42 CEST] <viric> brontosaurusrex: I remember one thing for avisynth there... outdated and beta.
[16:32:44 CEST] <furq> although i have no idea how much they cost
[16:33:03 CEST] <viric> jkqxz: who wants 10 live streams? from what?
[16:33:11 CEST] <Denis___> so, maybe someone knows what does it mean error -22 (Invalid argument)  on call avformat_alloc_output_context2  ?
[16:33:46 CEST] <jkqxz> viric:  What is the processor that you only get 60fps on there?
[16:33:52 CEST] <viric> jkqxz: an i3
[16:34:08 CEST] <warsh> furq: heh, I could always writing some vhdl code and taking advantage of the fpga on my desk
[16:34:12 CEST] <viric> jkqxz: I only tried transcoding h264, not live.
[16:34:31 CEST] <viric> jkqxz: Where can one get 10 sources of live video to encode?
[16:34:50 CEST] <jkqxz> "i3" contains no information.
[16:35:37 CEST] <viric> jkqxz: it's a toshiba c55-c 1t2
[16:35:59 CEST] <furq> i3-5005U apparently
[16:36:02 CEST] <viric> yes.
[16:36:11 CEST] <furq> http://ark.intel.com/products/84695/Intel-Core-i3-5005U-Processor-3M-Cache-2_00-GHz
[16:36:12 CEST] <jkqxz> For 10 streams, any sort of server context?  The graphics is the same throughout the line, so you get a lot of transcode capability on the lower SKUs because people actually want it on the higher ones.
[16:37:01 CEST] <jkqxz> Only 60fps suggests something is wrong with your setup.  You should get something like 200 on one of those.
[16:38:31 CEST] <pZombie> here is a benchmark with handbrake, showing various CPUs. 6950x is king
[16:38:35 CEST] <viric> jkqxz: maybe the bottleneck was the h264 decoding
[16:39:13 CEST] <jkqxz> If you decode in software, that would make sense.
[16:39:27 CEST] <viric> jkqxz: ah, so I get ~10 streams in my notebook because they already did that for some 'media servers'
[16:40:00 CEST] <viric> well, the hw decoder says that about "do not use multithread", so with threads 1 isn't very good either
[16:40:20 CEST] <viric> (and the hw decoder quality was worse, in vaapi. Not in nvidia)
[16:41:08 CEST] <jkqxz> ?  H.264 has one correct output - quality does not change.
[16:41:16 CEST] <viric> really? hm
[16:41:34 CEST] <viric> then maybe I have bad memories about that.
[16:41:47 CEST] <furq> you could have been trying to decode an unsupported pixel format or profile or something
[16:41:50 CEST] <warsh> ...ahhh, I justed converted the same file in micro video converter (which is just a pretty frontend for ffmpeg), and the video converts in seconds
[16:41:53 CEST] <furq> that would cause artifacting
[16:41:54 CEST] <warsh> >computers
[16:41:55 CEST] <pZombie> in theory, yes, but you rarely get that correct output from most players
[16:42:07 CEST] <viric> Definitely I saw a different bitrate in the output encoding, depending on whether I decoded with vaapi or with soft
[16:42:34 CEST] <viric> furq: unsupported by what? the hw decoder?
[16:42:39 CEST] <furq> yeah
[16:42:57 CEST] <viric> I'll test home and tell.
[16:42:59 CEST] <furq> although i'd have thought it would look obviously broken
[16:43:35 CEST] <viric> I don't remember seeing anything else than 'more blocky' and 'more bitrate'
[16:56:51 CEST] <kylophone> It doesn't appear FFmpeg is able to map the `COMM' id3 metadata field for mp3s.
[16:57:00 CEST] <kylophone> Can anyone confirm this?
[16:59:30 CEST] <pZombie> looks like smplayer is capable of playing back those seemingly corrupted webm videos ffmpeg generates on my PC
[16:59:39 CEST] <pZombie> smplayer on linux that is
[17:00:22 CEST] <pZombie> vlc on windows cannot play any webm, at least the version 2.2.2 i have installed does not seem to
[17:00:35 CEST] <pZombie> on linux however, it at least plays those generated with makewebm
[17:00:54 CEST] <pZombie> smplayer just plays anything i throw at it
[17:02:20 CEST] <brontosaurusrex> pZombie: smplayer is using mpv as backend or mplayer?
[17:02:46 CEST] <pZombie> i have no clue, just using linux installed inside vmware workstation rarely
[17:04:24 CEST] <pZombie> ah there we go
[17:04:34 CEST] <pZombie> i managed to produce a lossless vp9 video
[17:04:53 CEST] <pZombie> but of course it does not show it is lossless when playing it with ffplay or most other players
[17:05:42 CEST] <pZombie> it will show only in smplayer when setting the right renderer and make it also fit exactly the video within the player
[17:06:03 CEST] <pZombie> ffmpeg -i lagarith.avi -c:v libvpx-vp9  -qmin 0 -qmax 0 -lossless 1 -b:v 0  -threads 22 -tile-columns 6 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25 -c:a libopus -b:a 64k -f webm out.webm    what i used to create it
[17:06:20 CEST] <pZombie> it's lossless, good quality if you set smplayer up properly
[17:07:10 CEST] <pZombie> so my suspicion is that vp9 looks much better than we think it does
[17:07:26 CEST] <pZombie> the players just don't play it back properly
[17:09:56 CEST] <pZombie> here is a snapshot of the lossless recording inside smplayer http://i.imgur.com/gFwMajE.png
[17:10:03 CEST] <pZombie> it's 1:1 to the original
[17:12:40 CEST] <pZombie> trying with crf 20 now, to see if it will look good inside smplayer still with a lower file size
[17:12:48 CEST] <pZombie> that lossless one was almost 50mb
[17:12:58 CEST] <pZombie> half the size of the lagarith
[17:15:16 CEST] <pZombie> wow, this is amazing
[17:15:36 CEST] <pZombie> 17.6mb size now with crf 20 and it looks like the original still inside smplayer
[17:16:03 CEST] <pZombie> just the same as the lossless one
[17:16:07 CEST] <pZombie> no need for a screenshot
[17:16:23 CEST] <pZombie> the quality of vp9 is good!
[17:17:15 CEST] <pZombie> someone needs to fix ffplay to play videos as they should
[17:18:57 CEST] <Regda> to bad that youtube does not support vp9
[17:19:38 CEST] <Illya> pZombie why dont you fix ffplay, or sponsor someone to?
[17:19:52 CEST] <pZombie> i expected this was coming
[17:20:12 CEST] <pZombie> i would if it was within my reach
[17:20:21 CEST] <pZombie> i have produced software and supplied it for free
[17:21:12 CEST] <Regda> is it possible to use values like text_w from drawtext outside of his own filter (drawtext) ?
[17:31:09 CEST] <JEEB> pZombie: for reference render, always use mpv. its opengl renderer does things Right
[17:31:56 CEST] <JEEB> if ffplay was to be "fixed" it should use mpv's renderer if and when it'll get separated
[17:32:44 CEST] <pZombie> JEEB - not sure what mpv is, in smplayer what worked correctly, were various gl(opengl) renderers
[17:33:21 CEST] <JEEB> mpv is the least retarded mplayer fork atm
[17:33:36 CEST] <JEEB> smplayer kind of can use it but not properly
[17:33:55 CEST] <JEEB> it has a minimal on-screen ui
[17:34:05 CEST] <JEEB> so mpv filename.ext
[17:34:13 CEST] <pZombie> i don't get what i am missing on win10 for the ffmpeg created vp9 videos to either play in vlc or mpc-hc. Furq seems to have no problems with it
[17:34:41 CEST] <JEEB> for windows you can use the pre-built windows mpv binaries
[17:35:01 CEST] <pZombie> i might give that a try
[17:35:08 CEST] <pZombie> thanks for the info
[17:35:08 CEST] <JEEB> https://mpv.srsfckn.biz/
[17:35:24 CEST] <JEEB> windows binaries by lachs0r from #mpv
[17:36:12 CEST] <pZombie> wow
[17:36:25 CEST] <pZombie> it plays it right away and just right
[17:37:15 CEST] <JEEB> yeah and with mpv windows is properly supported as well. all the love.
[17:41:14 CEST] <redalert> Hello Guys, one Simple question
[17:41:57 CEST] <redalert> I  have one stream Where the Audio is mapped by default in Stream #0:0[0x100] and the Video is Mapped to Stream #0:1[0x101]
[17:42:23 CEST] <redalert> i want to draw a text on it using the filter and transcode that stream. Everything goes ok but
[17:42:41 CEST] <redalert> somehow the output file has the audio mapped to 0:1 and the video mapped to 0:0. Why ffmpeg changed the map on it's own?
[17:42:45 CEST] <redalert> i tried -map 0, but same happened
[17:44:37 CEST] <pZombie> i uploaded the crf 20 recorded VP9 video here https://drive.google.com/open?id=0BxMwFJfbOvWvNF9NRjJ1SnhGRHM
[17:46:57 CEST] <pZombie> the size is 17mb, so a bit large still for a 14sec video but the quality is basically lossless still, so i can probably use a higher crf and get good quality still
[17:47:14 CEST] <furq> pZombie: the vpx crf values don't map to the x264 crf values
[17:47:21 CEST] <furq> iirc the vpx range is higher
[17:47:50 CEST] <pZombie> trying crf 30 now
[17:48:11 CEST] <JEEB> yes, crf values differ even between presets within a single encoder, not to mention different encodrrs
[17:49:35 CEST] <pZombie> looks the same at crf 30 still
[17:49:40 CEST] <pZombie> 15mb now
[17:50:55 CEST] <kepstin> redalert: ffmpeg's default mapping is to pick the first video stream, then pick the first audio stream. it doesn't make any attempt to keep them in the same order. If you want a specific output mapping, use the -map option multiple times, per stream you want in the order you want.
[17:51:17 CEST] <kepstin> redalert: it usually doesn't matter, thought; why is the order being changed a problem?
[17:52:13 CEST] <pZombie> hm, even with crf 40 it looks like 1:1 to the original
[18:03:11 CEST] <pZombie> at crf 50, i get about the equal size of a x264 encoded video, using libx264rgb with crf 20. But the quality is definitely better in this case for the x264 video
[18:03:54 CEST] <pZombie> maybe there are smarter ways however to decrease the output file size other than just increasing crf on vp9
[18:05:02 CEST] <furq> -speed 1
[18:05:22 CEST] <pZombie> overall however, vp9 is pretty good, or would be, if it wasn't for the long encoding times.
[18:06:01 CEST] <furq> or -speed 0 even
[18:06:36 CEST] <pZombie> trying that now with crf 40
[18:08:58 CEST] <thebombzen> how does VP9 hold up to HEVC, which is the real test?
[18:09:13 CEST] <thebombzen> in terms of both compression ratios and encoding time?
[18:10:31 CEST] <pZombie> crf 40 and speed 0 got me to about the same size as the crf 20 encoded libx264rgb video
[18:10:44 CEST] <pZombie> and the quality seems to be equal, but i cannot tell for sure yet
[18:14:40 CEST] <pZombie> https://drive.google.com/open?id=0BxMwFJfbOvWvbWFUeXY0UVhuZkk  this is VP9 with crf40 and speed0, slightly lower in size than this https://drive.google.com/open?id=0BxMwFJfbOvWvUS1fNUp1ME5xRzQ  basically libx264rgb with crf 20
[18:15:06 CEST] <pZombie> quality is good on both, close enough to the original that i cannot tell the difference
[18:30:55 CEST] <_delta_> does anyone know how to use avcodec_send_packet() and avcodec_receive_frame() to decode audio? I'm having trouble
[18:47:36 CEST] Action: hawken_ looks around
[18:47:46 CEST] <hawken_> I'm trying some fun stuff, got a monitor here set to 72p exactly (3*24p)
[18:48:12 CEST] <hawken_> made a filter for ffmpeg that takes 1 video frame, makes up n black frames, and outputs the original frame + black frame
[18:48:23 CEST] <hawken_> so it will cause a lot of flickering, but
[18:48:30 CEST] <hawken_> Tries to emulate old CRTs
[18:49:08 CEST] <hawken_> then I was thinking, that the other methods we have for doing this is basically bilinear (average of two frames), nearest (duplicate) and then motion interpolation
[18:49:25 CEST] <hawken_> so I wondered if bicubic interpolation could be applied in this way (consider 2 previous and 2 next frames)
[18:49:32 CEST] <hawken_> or something..
[18:50:36 CEST] <hawken_> called it blackinsert (cause it inserts black frames :P)
[18:50:54 CEST] <iamtakingiteasy> hi, i am willing to attempt to programatically convert on-the-fly live RTMP stream containing .h264 & mp3 streams in flv container to h264 & mp3 (aac?) in DASH (debatable, it was just first thing i've found) segmented files for live html5 playback. could someone please advise me where to start? my final goal is  to provide html5 interface to live rtmp streams.
[18:51:01 CEST] <hawken_> takes a parameter factor.. 2 - inf (new framerate = factor * old framerate)
[18:51:37 CEST] <iamtakingiteasy> i already have implemented RTMP relaying server in golang and now thinking about next steps
[18:51:43 CEST] <hawken_> well iamtakingiteasy first thing you should know is that it should be possible to just copy h264 and mp3 so you won't need to reencode
[18:52:00 CEST] <hawken_> about dash I'm not too sure but I think ffmpeg has some support..
[18:52:06 CEST] <hawken_> then again I'm just a random dude
[18:52:19 CEST] <BtbN> iamtakingiteasy, why not just use an nginx-rtmp, stream to it via rtmp, and configure it to output hls and dash?
[18:52:39 CEST] <iamtakingiteasy> hawken_: h264 & aac should be fine in mp4 dash segments, not sure about mp3
[18:52:49 CEST] <hawken_> pretty sure mp3 is fine too..
[18:52:58 CEST] <iamtakingiteasy> BtbN: it'll require child ffmpeg process(es) for each stream
[18:53:03 CEST] <BtbN> no
[18:53:15 CEST] <iamtakingiteasy> also, it was not playing very well in my tests with reference DASH player
[18:53:24 CEST] <BtbN> It supports DASH and HLS natively.
[18:53:55 CEST] <iamtakingiteasy> indeed it is, sorry, i had to state that i have to conceal actual stream names
[18:54:24 CEST] <iamtakingiteasy> so i receive something like live/<md5hash> from publisher and share it to everyone as live/iamauser
[18:55:11 CEST] <iamtakingiteasy> i am doing a low-latency streaming services for me and my friends
[18:55:17 CEST] <hawken_> That can't be too hard to fix, I bet you can just relay the rtmp stream internally
[18:55:22 CEST] <BtbN> low latency is not going to happen with both DASH and HLS
[18:55:39 CEST] <BtbN> They have at least segment duration times 3 of additional latency.
[18:55:51 CEST] <iamtakingiteasy> hawken_: nope, it is not doable without a child ffmpeg process relaying from md5hash to iamauser, i've checked this
[18:55:54 CEST] <hawken_> if you want a zero latency option I think you could just make some aliases in nginx-rtmp..
[18:56:08 CEST] <hawken_> Maybe you have to go to the source but yeah
[18:56:10 CEST] <BtbN> iamtakingiteasy, you should read the nginx-rtmp documentation again.
[18:56:13 CEST] <iamtakingiteasy> BtbN: fine, currently i am trying just to satisfy flash-less clients
[18:56:39 CEST] <iamtakingiteasy> BtbN: there are events, allowing to change the stream name in RTMP solely, but not when DASH or HLS is involved
[18:56:54 CEST] <iamtakingiteasy> DASH for instance leaks publisher MD5 hash in MPD file
[18:56:54 CEST] <BtbN> Just push the input stream to some other "app", and configure dash/hls there.
[18:57:15 CEST] <EvanR> sweet
[18:57:16 CEST] <iamtakingiteasy> and how do you connect two apps without ffmpeg child process for each stream?
[18:57:33 CEST] <BtbN> by pushing from one to the other, as documented in their documentation.
[18:57:52 CEST] <iamtakingiteasy> hm.
[18:57:53 CEST] <hawken_> holy.. shite.. With my flicker generating filter, the panning was waayy easier to follow with my eyes
[18:57:57 CEST] <asteele> hi i am using ffmpeg to convert audio files from mp3 to ogg on upload, but for some reason all of the resulting files are only 2 seconds long, any clues on what i should look for?
[18:58:34 CEST] <hawken_> asteele: depends on your command line options..
[18:58:46 CEST] <asteele> ffmpeg -y -i %s -acodec libvorbis -f ogg %s
[18:58:47 CEST] <EvanR> i am trying to capture screen video with OSX, avfoundation driver. my command line is ffmpeg -f avfoundation -i "1:0" out.mov, and using all available pixel formats i get a variety of images which appear to have each row shifted by an increasing amount
[18:58:54 CEST] <asteele> wheres %s is the input/output file
[18:59:25 CEST] <EvanR> its like each row is missing 1 or more pixels on one of the sides,
[18:59:32 CEST] <hawken_> and the resulting file is only 2 sec? Got any output from ffmpeg?
[18:59:33 CEST] <EvanR> so the picture is slanted
[19:00:09 CEST] <asteele> yea resulting file is only 2 secs, no output from ffmpeg but i am running via exec in php, so let me get it setup to just run the raw command in cli, sec
[19:00:31 CEST] <EvanR> ive seen references to maybe my resolution of 1366x768 does not play nice with swscalar SSE alignment requirements
[19:00:52 CEST] <iamtakingiteasy> BtbN: i still don't get it how to hook-up onto event when pull/push is being performed to substitute MD5 hash with some huaman-ish name
[19:01:05 CEST] <iamtakingiteasy> without resorting to shell process
[19:01:07 CEST] <BtbN> no idea what event you are talking about.
[19:01:24 CEST] <hawken_> asteele: basically I think you need a test file that reproduces the problem
[19:01:36 CEST] <hawken_> If the input file is not corrupt I really don't see how it can be possible
[19:01:41 CEST] <iamtakingiteasy> BtbN: there are a number of events, like on_publish, on_play, etc in nging-rtmp
[19:01:56 CEST] <BtbN> you don't need those.
[19:01:58 CEST] <hawken_> or maybe the output is cropped somehow
[19:01:59 CEST] <iamtakingiteasy> how so?
[19:02:09 CEST] <iamtakingiteasy> i can't show MD5 hash of publisher publically
[19:02:20 CEST] <iamtakingiteasy> it should be his private stream name
[19:02:26 CEST] <asteele> hawken_ getting it into a more reproducable state now, few mins, ty for your help so far
[19:02:40 CEST] <iamtakingiteasy> the token that lats identify one as authorized publisher
[19:02:43 CEST] <iamtakingiteasy> lets*
[19:03:16 CEST] <iamtakingiteasy> so i have to substitute md5 with some user-picked name at some point
[19:03:24 CEST] <asteele> do i need the libvorbis encoder for mp3 -> ogg ?
[19:03:39 CEST] <hawken_> asteele: ^-^ ogg is just a container, it can contain many different formats, so yes
[19:03:46 CEST] <hawken_> but I think -acodec libvorbis is the default
[19:03:46 CEST] <iamtakingiteasy> i can do this (doing right now) with nginx-rtmp and few redirect calls to http services for on_publish, but thats not really wrking for hls and dash
[19:03:58 CEST] <asteele> right now its saying it doesnt have libvorbis encoder
[19:04:03 CEST] <hawken_> wait what
[19:04:04 CEST] <iamtakingiteasy> only for rtmp solely
[19:04:05 CEST] <asteele> the vm is ubuntu, so trying to figure that out
[19:04:06 CEST] <hawken_> ffmpeg -codecs then maybe
[19:04:17 CEST] <hawken_>  DEA.L. vorbis               Vorbis (decoders: vorbis libvorbis ) (encoders: vorbis libvorbis )
[19:04:43 CEST] <iamtakingiteasy> so i'm afraid i am back to my original question... where to start learning programmatic (C?) interface to ffmpeg?
[19:04:58 CEST] <hawken_>  DEA.L. vorbis               Vorbis (decoders: vorbis libvorbis ) (encoders: vorbis libvorbis )
[19:05:01 CEST] <_delta_> iamtakingiteasy: check out the examples
[19:05:08 CEST] <asteele> yeah i see that hawken_
[19:05:21 CEST] <hawken_> what does it say in your "encoders" list?
[19:05:27 CEST] <iamtakingiteasy> _delta_: okay, thanks
[19:05:38 CEST] <hawken_> I think maybe it was compiled without libvorbis in which case I think -acodec vorbis will workj
[19:05:43 CEST] <asteele> ffmpeg -codecs | grep vorbis
[19:05:49 CEST] <asteele> DEA.L. vorbis               Vorbis (decoders: vorbis libvorbis ) (encoders: vorbis libvorbis )
[19:06:03 CEST] <hawken_> so... schroedingers libvorbis
[19:06:30 CEST] <hawken_> I think -acodec libvorbis will work for you
[19:06:31 CEST] <asteele> :o
[19:06:46 CEST] <asteele> as opposed to, -acodec -libvorbis ?
[19:06:53 CEST] <hawken_> wait what, did you add a dash
[19:06:56 CEST] <hawken_> then of course it won't work
[19:07:15 CEST] <asteele> yea there was a dash lol, im debugging a coworkers thing he did before he left for vacation ;p
[19:07:24 CEST] <hawken_> ok that dash shouldn't be there
[19:07:38 CEST] <asteele> oh yeah it isnt in his code, i derped and added it when i was copying over, fuark, k sec
[19:08:19 CEST] <asteele> hmmm
[19:08:30 CEST] <asteele> the raw command seemed to have worked fine
[19:08:46 CEST] <asteele> and the output file is good
[19:08:51 CEST] <asteele> let me do some more testing...
[19:09:11 CEST] <hawken_> ok the next thing.. I would check if the .ogg file is corrupted
[19:09:16 CEST] <hawken_> ffmpeg -i test.ogg -f null -
[19:09:29 CEST] <hawken_> will decode the whole file, should exit gracefully if the file is fine
[19:10:29 CEST] <asteele> hmm
[19:10:34 CEST] <asteele> yeah seems like that worked okay
[19:10:41 CEST] <_delta_> are there any examples of using avcodec_send_packet() and avcodec_receive_frame() instead of the now deprecated avcodec_decode_audio()? all of the examples I can see use avcodec_decode_audio().
[19:11:38 CEST] <asteele> so isolated it seems to work fine, that is good, anything about my implementation sound like it would go weird?  Basically when a user uploads a file to the server via php, it gets stored in a temp file, if it is mp3, we use ffmpeg on the temp file to convert it in its place to ogg format, then after that other code moves it to amazon s3
[19:12:09 CEST] <BtbN> iamtakingiteasy, remembered this wrong. They indeed use ffmpeg for pushing in their examples. It still works fully automatic though, and is well documented: https://github.com/arut/nginx-rtmp-module/wiki/Directives#exec_push
[19:12:34 CEST] <hawken_> asteele: so, does either the mp3 or the ogg file get truncated at any point?
[19:13:23 CEST] <asteele> i dont believe so, at least not intentionally
[19:14:00 CEST] <iamtakingiteasy> BtbN: yeah, only requires the process in the middle
[19:14:22 CEST] <zamba> can someone help me with a/v sync issues?
[19:14:32 CEST] <hawken_> ok, so the 2 second file is not corrupted, and the ffmpeg command works?
[19:14:48 CEST] <iamtakingiteasy> BtbN: but you're not wrong about pushing; if you simply want to move stream from one app to another, you can use https://github.com/arut/nginx-rtmp-module/wiki/Directives#push
[19:14:49 CEST] <hawken_> T_T ok maybe you should look for logs
[19:14:56 CEST] <hawken_> ffmpeg would definitely say what happened
[19:15:16 CEST] <asteele> okay give me a few mins, trying some scenarios and stuff
[19:15:21 CEST] <asteele> to try to find out where its going wrong
[19:15:42 CEST] <iamtakingiteasy> BtbN: but that is not exactly what i want; i want to *rename* the stream itself according to my database mappings between md5 hashes and stream names
[19:16:27 CEST] <iamtakingiteasy> BtbN: and this works with rtmp-only on_publish http service returning redirect, but not with dash/hls
[19:17:24 CEST] <hawken_> iamtakingiteasy: tbh I think modifying nginx-rtmp is easier
[19:17:30 CEST] <hawken_> you could probably get help from their devs too
[19:17:53 CEST] <hawken_> nginx-rtmp seems to do everything except that detail
[19:18:07 CEST] <hawken_> https://helping-squad.com/nginx-rtmp-how-to-use-secure-links/
[19:18:08 CEST] <iamtakingiteasy> hawken_: yeah, you're right. but what fun will be in it?
[19:18:15 CEST] <hawken_> They have this though, maybe it can apply to your case
[19:18:22 CEST] <hawken_> fun? well it can make life easier for everyone
[19:18:28 CEST] <hawken_> that's pretty fun :3
[19:19:05 CEST] <BtbN> iamtakingiteasy, you can use that push to push to another app in the very same nginx-rtmp on localhost.
[19:19:09 CEST] <BtbN> And then do hls/dash there.
[19:19:16 CEST] <EvanR> trying again after building the git version
[19:19:17 CEST] <iamtakingiteasy> BtbN: and when to rename it?
[19:19:36 CEST] <BtbN> hardcode the destination in the url you're pushing to.
[19:19:41 CEST] <hawken_> if he wants low latency then what fun is that
[19:19:46 CEST] <hawken_> ah
[19:19:49 CEST] <iamtakingiteasy> BtbN: sorry?
[19:19:49 CEST] <hawken_> but you don't have to
[19:19:56 CEST] <hawken_> the exec things can exec a script
[19:20:00 CEST] <hawken_> which can look up in the database
[19:20:07 CEST] <BtbN> don't use a variable for the stream name, just hardcode it.
[19:20:26 CEST] <hawken_> my eyes are flickering from watching 24Hz flickering movies :o
[19:20:33 CEST] <BtbN> you can't realy do much more via ffmpeg anyway.
[19:20:36 CEST] <iamtakingiteasy> but i have a number of publishers, each with number of streams
[19:20:38 CEST] <hawken_> I think that this filter better be kept a long way from epileptics :o
[19:20:50 CEST] <iamtakingiteasy> yah, i could use exec_publish to lookup the database
[19:20:51 CEST] <BtbN> yeah, that can't be done then. Not even using ffmpeg.
[19:21:03 CEST] <hawken_> iamtakingiteasy: if they push to one area like /push/<md5>
[19:21:11 CEST] <BtbN> You'd need some more intelligent external wrapper around ffmpeg then.
[19:21:12 CEST] <hawken_> then you can hook a script that looks up your mapping in the database
[19:21:17 CEST] <hawken_> then republishes it under /live/
[19:21:31 CEST] <hawken_> yes, it does do ffmpeg which you said you coduldn't
[19:21:35 CEST] <iamtakingiteasy> yeah, it is similar to how it is working now
[19:21:39 CEST] <hawken_> in which case maybe it's time to extend what nginx-rtmp can do
[19:21:44 CEST] <iamtakingiteasy> but i already implemented RTMP protocol from scratch :3
[19:21:50 CEST] <hawken_> lol
[19:21:52 CEST] <iamtakingiteasy> would be a waste to stop thee
[19:22:02 CEST] <hawken_> then why are you even asking here, you know what to do :P
[19:22:07 CEST] <hawken_> ah HLS stuff
[19:22:13 CEST] <hawken_> now you have to implement HLS from scratch
[19:22:19 CEST] <iamtakingiteasy> yep!
[19:22:21 CEST] <hawken_> well you get no magic pill from me, enjoy
[19:22:36 CEST] <iamtakingiteasy> okay, that was worth trying %)
[19:23:19 CEST] <hawken_> I think ffmpeg more or less always introduces latency
[19:23:26 CEST] <hawken_> so I don't think ffmpeg then is the right tool for the job
[19:23:32 CEST] <BtbN> HLS/DASH introduce latency. A lot.
[19:23:49 CEST] <iamtakingiteasy> i hope they can be tweaked to minimize it
[19:23:57 CEST] <BtbN> No
[19:24:08 CEST] <BtbN> 6 seconds is the bare minimum, under perfect conditions.
[19:24:12 CEST] <BtbN> Usualy more like 12
[19:25:00 CEST] <BtbN> And you need special encoding options to even reach these, which severely reduce the possible quality
[19:25:04 CEST] <iamtakingiteasy> hrm. what about letting downloads html5 mp4 "file" as fast as stream goes for regular html5 setup?
[19:25:13 CEST] <BtbN> mp4 is not streamable.
[19:25:19 CEST] <BtbN> That's why DASH was invented.
[19:25:22 CEST] <iamtakingiteasy> ah.
[19:25:25 CEST] Action: hawken_ prefers mpeg-ts
[19:25:32 CEST] <BtbN> Browsers can't play mpeg-ts.
[19:25:40 CEST] <hawken_> then screw browsers :3
[19:25:53 CEST] <furq> do you have an alternative
[19:26:00 CEST] <furq> please tell me you have an alternative. i'll give you so much money
[19:26:04 CEST] <furq> you can have my kids
[19:26:08 CEST] <EvanR> is there a ffmpeg dev channel
[19:26:13 CEST] <furq> #ffmpeg-devel
[19:26:31 CEST] <BtbN> Depends on what you mean by dev. That one is for development of ffmpeg itself, not developing using its libraries.
[19:26:31 CEST] <hawken_> so how does rtmp compare to all of this? personally I think flv is about as good as cancer
[19:26:43 CEST] <furq> rtmp compares extremely favourably if you ignore the bit about flash
[19:26:48 CEST] <BtbN> flv is a decent format, simple and does what it's supposed to do.
[19:26:53 CEST] <furq> it's an actual streaming protocol and an actual streaming format
[19:26:58 CEST] <hawken_> except doesn't support my fav codecs
[19:27:01 CEST] <furq> and not a big heap of shit dumped on top of http for no reason
[19:27:15 CEST] <BtbN> It supports h264 and aac, which is widely supported.
[19:27:20 CEST] <hawken_> flac? hevc?
[19:27:25 CEST] <iamtakingiteasy> hawken_: well, rtmp is necessery evil, as most streaming software front-ends can do rtmp only :/
[19:27:34 CEST] <BtbN> hevc supports is being worked on. And nobody cares about flac.
[19:27:36 CEST] <furq> does dash support flac
[19:27:45 CEST] <hawken_> what about raw pcm
[19:27:54 CEST] <BtbN> Even worse.
[19:27:58 CEST] <BtbN> Why would anyone want that?
[19:28:09 CEST] <hawken_> so basically, why would anyone want streaming of lossless audio
[19:28:13 CEST] <furq> lpcm is supported in flv
[19:28:56 CEST] <pZombie> what's the status of vp9 currently when it comes to using it commercially? Will patent holders come after you?
[19:29:13 CEST] <hawken_> I think vp9 is about making things more open than hevc
[19:29:18 CEST] <hawken_> so hopefully not?
[19:29:29 CEST] <furq> google are the license holders for vp9
[19:29:32 CEST] <TD-Linux> pZombie, it is absolutely better if you don't pay a license
[19:29:41 CEST] <furq> they have some kind of shadowy agreement with mpeg-la regarding potential patents
[19:29:51 CEST] <hawken_> it's google
[19:29:55 CEST] <furq> i doubt it's watertight but it's as good as you're going to get until daala/AV1 is usable
[19:29:59 CEST] <hawken_> as long as they decide to keep it open, it will be open
[19:29:59 CEST] <pZombie> yes, that shadowy agreement is what i do not understand
[19:30:04 CEST] <furq> nobody does
[19:30:25 CEST] <furq> it grants google the right to issue a license for vp8, and i assume by extension vp9
[19:30:29 CEST] <furq> which they do for free
[19:30:43 CEST] <furq> but i have no idea if it clears vpx users of patent claims
[19:30:55 CEST] <TD-Linux> you can never clear anyone of all patent claims
[19:31:01 CEST] <furq> yeah
[19:31:07 CEST] <hawken_> the US patent system is messed up tho
[19:31:24 CEST] <pZombie> hawken_ it's not that simple. If patent holders which are after your money$$ can claim that vp9 utilizes their patents, they can come after you if you ever run a for profit site that plays vp9 videos
[19:31:35 CEST] <furq> anyone can claim anything infringes their patents though
[19:31:36 CEST] <TD-Linux> they can do the same for any other video format too
[19:31:38 CEST] <TD-Linux> or audio format
[19:31:54 CEST] <hawken> pZombie: I think at this point, people just rely on the actual chance that it will happen
[19:32:01 CEST] <hawken> because nobody are safe from that screwed patent system
[19:32:11 CEST] <furq> if you're based in the eu it's not a big deal really
[19:32:17 CEST] <pZombie> we need to find a way to get rid of the patent-holders
[19:32:21 CEST] <furq> unless you're making a shitload of money
[19:32:34 CEST] <furq> or rely on being able to sell products to the us
[19:32:38 CEST] <hawken> like youtube? oh wait, they are a part of google :P
[19:32:42 CEST] <hawken> I like how open the market is
[19:32:55 CEST] <furq> huh
[19:33:23 CEST] <TD-Linux> EU is mostly safer because there is less money there
[19:33:38 CEST] <hawken> and umm.. mpeg-la has no authority here?
[19:33:53 CEST] <TD-Linux> mpeg-la only licenses patents in their pool
[19:34:25 CEST] <TD-Linux> you can pay them and get a license to their patents, but there may be more patents outside of their pool
[19:34:47 CEST] <hawken> which nobody does outside of the US because the US patent system is only valid inside of USA...
[19:35:08 CEST] <TD-Linux> right, but they license a lot of EU patents as well
[19:35:32 CEST] <hawken> oh sh** *goes completely amish*
[19:36:17 CEST] <furq> just never do anything ever and you'll be fine
[19:40:53 CEST] <pZombie> So i compressed this http://4ksamples.com/ses-astra-uhd-test-2-2160p-uhdtv/ 4k sample video to VP9 640x360 https://drive.google.com/open?id=0BxMwFJfbOvWvXzlxSkxtazFSNEU  . Looks quite impressive to me, at 5.5mb size only
[19:50:04 CEST] <jnorthrup> is anyone in here using an rdf media description of assets/ingestion, etc. in here?
[19:51:00 CEST] <jnorthrup> ... or even an xml descriptor with open xsd's ?
[20:05:49 CEST] <rkern> EvanR: I don't have the resolution you mentioned in #ffmpeg. It works at a few different resolutions I tested - 1280x720, 960x540, 1024x576.
[20:06:08 CEST] <rkern> Can you find the commit that broke it with git bisect?
[20:06:21 CEST] <EvanR> oh, do you think it was working?
[20:06:37 CEST] <EvanR> i just tried in the git version, still not working
[20:06:55 CEST] <EvanR> i will begin the bisect process
[20:07:17 CEST] <EvanR> also i just tried building with sse2 disabled just in case that was the issue
[20:07:22 CEST] <EvanR> didnt work
[20:08:24 CEST] <rkern> Does it happen with other resolutions?
[20:09:03 CEST] <EvanR> i cant change the rez on this mac book air
[20:09:31 CEST] <EvanR> looks like i have to find a commit where it was working to do a bisect
[20:10:29 CEST] <rkern> See if an older release works
[20:11:59 CEST] <EvanR> how far back should i go, when was avfoundation invented?
[20:17:00 CEST] <rkern> EvanR: 2.5 is pretty old.
[20:18:09 CEST] <EvanR> unknown configure option libopenh264...
[20:18:40 CEST] <rkern> try `make distclean && ./configure`
[20:19:13 CEST] <rkern> what's your configure line?
[20:19:49 CEST] <EvanR> its long
[20:20:01 CEST] <EvanR> i went back to the initial commit of avfoundation.m
[20:20:12 CEST] <EvanR> to see what would happen
[20:20:25 CEST] <EvanR> ./configure --enable-gpl --enable-version3 --enable-nonfree --enable-shared --enable-libass --enable-libfdk-aac --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libx264 --enable-opengl
[20:22:14 CEST] <EvanR> make: *** No rule to make target `libavcodec/aacdec_template.c', needed by `libavcodec/aacdec.o'.  Stop.
[20:22:49 CEST] <EvanR> ill try 2.5
[20:25:28 CEST] <EvanR> same error
[20:29:30 CEST] <rkern> EvanR: did you run configure first?
[20:30:22 CEST] <EvanR> yes
[20:30:32 CEST] <EvanR> im doing 2.6 now and it get past that point
[20:30:41 CEST] <EvanR> maybe because i did make distclean
[20:36:02 CEST] <EvanR> heh list-devices still gives input/output error at the end,
[20:36:50 CEST] <EvanR> in 2.6 it is still doing the same thing
[20:37:04 CEST] <EvanR> so maybe it never worked
[20:39:05 CEST] <rkern> ok, can you file a bug on trac along with a short media sample and ffmpeg output (using master)?
[20:40:31 CEST] <EvanR> yes, do you have tips on exactly what kind of output would be most helpful
[20:40:35 CEST] <EvanR> in addition to the .mov file
[20:43:03 CEST] <rkern> a raw yuv frame would be helpful too
[20:43:39 CEST] <EvanR> how do you do that
[20:46:32 CEST] <EvanR> ... connection keeps timing out when i try to create account
[20:48:38 CEST] <EvanR> things arent going my way today...
[20:48:44 CEST] <EvanR> i need coffee
[20:48:52 CEST] <EvanR> "trac.ffmpeg.org took too long to respond."
[20:52:07 CEST] <rkern> had to look it up... try `-frames:v 1 -c:v rawvideo out.yuv` instead of `out.mov`
[20:54:09 CEST] <rkern> ok, well you can post a link to the media files here for now. I'll check back later tonight.
[20:58:10 CEST] <hyponic> is there a bug in ffmpeg when trying to convert dvb_teletext to dvb_subtitle? coversion fails when trying to do the following: ffmpeg -v debug -i test_subs01.ts -vcodec copy -acodec copy -scodec dvbsub test_subs03.ts
[20:58:17 CEST] <hyponic> ffmpeg output uncut: http://pastebin.com/u1mpizxu
[21:01:35 CEST] <agrathwohl> Say I wanted to use FFmpeg's CLI to make five outputs from a single input file. Are there efficiency, performance, or quality gains from using the `-filter_complex` option, as opposed to running five instances of FFmpeg in parallel?
[21:11:36 CEST] <furq> you don't have to decode the source five times
[21:12:42 CEST] <pomaranc> you don't even have to use filter_complex
[21:13:14 CEST] <furq> well that depends on how accurate the question is
[21:13:46 CEST] <kepstin> depending on what exactly you're doing with the 5 outputs, you might get bottlenecked by some of the single-threaded parts of ffmpeg.
[21:14:17 CEST] <hyponic> anyone?
[21:15:07 CEST] <kepstin> hyponic: isn't that converting from a text format to an image format? I'm not sure ffmpeg really supports that.
[21:15:23 CEST] <furq> if it doesn't support it then it probably shouldn't attempt it
[21:16:30 CEST] <hyponic> furq if it doesn't what other options are there?
[21:16:46 CEST] <furq> i have no idea whether or not it supports it
[21:17:10 CEST] <furq> but normally if something isn't supported then ffmpeg won't start trying to encode it
[21:19:09 CEST] <hyponic> furq exactly.. but it does
[21:19:45 CEST] <furq> also "converting from a text format to an image format" is more or less what -vf subtitles does
[21:20:04 CEST] <kepstin> sure, but that generates a video stream, not a subtitle stream.
[21:20:17 CEST] <kepstin> (or rather, renders on top of a video stream)
[21:20:53 CEST] <furq> ffmpeg -codecs claims there's a dvb_subtitle encoder
[21:20:58 CEST] <furq> i don't see why it wouldn't be able to generate them
[21:21:02 CEST] <furq> obviously going the other way is a different issue
[21:21:18 CEST] <kepstin> I'm pretty sure the encoder lets you transcode other formats of image-based subs
[21:21:29 CEST] <kepstin> e.g. maybe you can transcode blu-ray subs to dvb?
[21:21:48 CEST] <furq> probably
[21:21:52 CEST] <furq> i'm not trying to claim it should work
[21:22:09 CEST] <furq> or that it does work, rather
[21:25:42 CEST] <BigJon> Hi ... I'm really struggling to use ffmpeg on windows ? I downloaded it from ffmpeg.org. I have JPG files from my security camera in the form image16-06-17_05-15-43-32.jpg I cant seem to get ffmpeg to concatinate them in to an MPG video. IIUIC the glob function doesnt work on windows ? Do I have any choice but to rename the all image001.jpg, image002.jog, etc ?! I have 26,000 images a day !
[21:25:42 CEST] <BigJon> I'd rather find a way to use them as is ? Thanks ! Jon.
[21:26:25 CEST] <BigJon> I tries this : ffmpeg -i image16-06-17*.jpg image16-06-17.mpg
[21:26:47 CEST] <furq> put -pattern_type glob before -i
[21:27:01 CEST] <BigJon> that doesnt work on windows
[21:27:03 CEST] <llogan> i don't think the glob function works on builds from Zeranoe. But I may be wrong...not a Windows user.
[21:27:24 CEST] <hyponic> kepstin furq here is a link to the file. http://151.80.97.148/test_subs02.ts could any of you try to help me figure it out?? it got me scratching my head for a long time now!
[21:28:01 CEST] <BigJon> with glob I get : Pattern type 'glob' was selected but globbing is not supported by this libavformat build
[21:28:02 CEST] <BigJon> image16-06-17_05-11-*.jpg: Function not implemented
[21:28:12 CEST] <furq> i guess you need to rebuild ffmpeg or rename the images then
[21:28:19 CEST] Action: BigJon sobs
[21:28:36 CEST] <furq> i would say it'd be fairly trivial to rename them with a script, but this is windows isn't it
[21:28:38 CEST] <furq> land of great scripting
[21:28:43 CEST] <BigJon> :-)
[21:28:51 CEST] <BigJon> its just there are so many ..
[21:29:07 CEST] <llogan> if you do rename make sure to use zero padding: 0001.foo instead of 1.foo
[21:29:09 CEST] <spooooon> Anyone here have experience depacketizing MJPEG stream? I'm here tearing my hair out for 2 days
[21:29:12 CEST] <BigJon> every day I would need to rename 28,000 image
[21:30:03 CEST] <kepstin> BigJon: the number of them isn't really relevant once you have the script to rename them...
[21:30:23 CEST] <BigJon> true. just a pain.
[21:30:50 CEST] <BigJon> no worries. Thanks for helping. I was hoping there was some magic command I hadnt noticed, like a file I could create listing all the input files ...
[21:31:15 CEST] <BigJon> or a magic regex I could use to match my date format in the file ...
[21:31:29 CEST] <llogan> does Windows have cat? then you can do something like "cat *.png | ffmpeg -f image2pipe -i - ..."
[21:31:54 CEST] <BigJon> dir /b does the same ?
[21:32:07 CEST] <BigJon> it would generate a list of files ?
[21:32:32 CEST] <llogan> cat feeds the images to ffmpeg via the pipe
[21:32:38 CEST] <BigJon> Oh I see, sorry, miunderstood ... you mean cat the images on stdin
[21:33:38 CEST] <BigJon> I could use cygwin
[21:33:48 CEST] <BigJon> and cat from there.
[21:35:10 CEST] <kepstin> if you were using cygwin, you could build a cygwin version of ffmpeg that supports globs :)
[21:35:49 CEST] <furq> http://vpaste.net/eqpN1
[21:35:55 CEST] <furq> if you do end up using cygwin/msys
[21:36:30 CEST] <furq> image2pipe might be a better approach because it's non-destructive
[21:36:50 CEST] <llogan> you could use symlinks instead
[21:36:55 CEST] <furq> yeah i was just typing that
[21:37:31 CEST] <furq> i'm sure you could replicate that script in batch, but you're on your own there
[21:37:39 CEST] <BigJon> :-)
[21:37:40 CEST] <BigJon> Thanks
[21:37:53 CEST] <BigJon> symlinks might work .. then there's no renameing / copying ...
[21:38:17 CEST] <BigJon> I could create the symlinks for one day, generate the MPG, then delete the symlinks, rinse and repeat.
[21:38:25 CEST] <furq> yeah please don't run that script unaltered on security camera footage because i've not tested it
[21:38:34 CEST] <BigJon> np
[21:39:17 CEST] <EvanR> rkern: i managed to get the ticket into trac https://trac.ffmpeg.org/ticket/5654
[21:39:50 CEST] <furq> also i forgot i wasn't using a proper programming language
[21:40:27 CEST] <furq> http://vpaste.net/Ypkbg
[21:40:28 CEST] <furq> there
[21:44:05 CEST] <rkern> EvanR: thanks
[21:44:53 CEST] <EvanR> if you have any tips on what i can do on my end to find the issue...
[21:45:11 CEST] <EvanR> though im pretty behind on video theory
[21:47:07 CEST] <EvanR> but since its my computer exhibiting the problem i can try to help
[21:48:04 CEST] <BigJon> furq: Thanks
[21:50:30 CEST] <rkern> EvanR: you could look around in libavdevice/avfoundation.m. Rough guess is it's related to the linesize (byte width of one row in memory). You could also try a different encoder to see if that's any different.
[21:50:41 CEST] <rkern> otherwise I'll take a look later on
[21:50:55 CEST] <EvanR> i tried .avi is that what you mean
[21:52:53 CEST] <EvanR> ok
[21:54:14 CEST] <EvanR> image_buffer_size = CVImageBufferGetEncodedSize(image_buffer); ...
[21:54:52 CEST] <rkern> you could try `-c:v h264_videotoolbox out.mov` to use a different h.264 encoder (on master, not in a release)
[21:58:05 CEST] <EvanR> yeah same thing, just worse quality
[21:58:22 CEST] <EvanR> only at least this opens in quicktime
[21:58:49 CEST] <EvanR> whatever is generating the AVFContext must be putting the wrong width in there
[21:59:07 CEST] <EvanR> and it should be somewhere in the same file
[22:32:06 CEST] <zamba> kepstin: you around?
[22:32:12 CEST] <EvanR> rkern: well somebody closed by ticket as a duplicate, but the workaround referenced in the "duplicate" (I'm not even sure if its the same symptoms) don't have any effect for me...
[22:32:19 CEST] <EvanR> my ticket
[22:41:43 CEST] <agrathwohl> kepstin: this was my concern, too. the five outputs will all be MP4 files containing H.264 + AAC bitstreams, (AAC bitstreams will be stream copied from the initial input file, an MOV containing a ProRes and an AAC bitstream).
[22:56:27 CEST] <rkern> EvanR: ok - I'll check it out
[23:53:37 CEST] <vladashram> I was just sitting here thinking(I know, dangerous right?): Why do people refer to h.265 as HEVC, but don't call h.264 AVC?
[23:54:10 CEST] <furq> people do call h.264 avc
[23:54:32 CEST] <JEEB> I do at least, but in general I find it easier to write than the former ITU-T name
[23:54:47 CEST] <JEEB> also back when I started working on HEVC ITU-T hadn't yet named it
[23:55:04 CEST] <seangrove> Hey all, I'm trying to programmatically quit ffmpeg - sending SIGINT 1 makes it exit early and it doesn't properly write the length info as though I had hit `q`
[23:55:06 CEST] <t3v4> Hi all :) Can someone here clarify for me some enums in ffmpeg related to fft?
[23:55:08 CEST] <t3v4> :)
[23:55:10 CEST] <JEEB> or well, taken the spec into tis repertoire officiailly
[23:55:12 CEST] <JEEB> *officially
[23:55:20 CEST] <furq> why does nobody call it mpeg-h part 2
[23:55:23 CEST] <furq> that's obviously the best name
[23:55:29 CEST] <JEEB> MPEG Ecchi
[23:55:30 CEST] <JEEB> yes,
[23:55:31 CEST] <JEEB> best indeed
[23:55:32 CEST] <Freakshow> thats what I call it.
[23:55:47 CEST] <Freakshow> Just so people will stop talking to me
[23:55:50 CEST] <furq> the h stands for hyperactive
[23:55:58 CEST] <JEEB> they also got the 3d audio spec ready it seems
[23:55:59 CEST] <seangrove> This is on Ubuntu 14.04, so I thought plain `kill -1 <ffmpeg-pid>` would be sufficient for it to exit cleanly, but it seems not
[23:56:22 CEST] <JEEB> https://www.itscj.ipsj.or.jp/sc29/29w42911.htm#MPEG-H
[23:56:33 CEST] <JEEB> and MMT is still lolwut
[23:56:47 CEST] <c_14> seangrove: SIGINT is 2, SIGHUP is 1
[23:57:07 CEST] <seangrove> c_14: Ah, I should send `kill -2` then?
[23:57:13 CEST] <c_14> just kill -INT
[23:58:01 CEST] <seangrove> Bah, thought INT was a placeholder for INTEGER :P
[23:58:03 CEST] <seangrove> Thanks
[00:00:00 CEST] --- Tue Jun 21 2016