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

[burek]

[00:50:03 CEST] <kepstin> kyleogrg: not in the sense of x264's psy tunings (film, animation, grain, etc.). It does have an option to bias for ssim vs. psnr metric measurements.
[00:50:37 CEST] <kepstin> hmm. actually, that was in vp8 - but I don't think they've added any in vp9 either
[00:51:38 CEST] <kyleogrg> kepstin: ok, thanks
[00:52:56 CEST] <kepstin> note that 'x264 --fullhelp' prints out what the tunes actually do; in some cases, you might be able to do something similar with vp9 if you understand what the individual options mean :/
[00:53:39 CEST] <kyleogrg> kepstin: like: ffmpeg x264 --fullhelp?
[00:53:51 CEST] <kepstin> no, running the 'x264' command line tool
[00:54:10 CEST] <kepstin> but I suspect most of the options don't have any direct counterparts, and vp9 is somewhat less tweakable overall
[00:54:41 CEST] <kyleogrg> i've never really used anything but ffmpeg.  is there a vp9 binary i can download?
[00:55:18 CEST] <kepstin> there's a standalone encoder called 'vpxenc', but you probably want to use ffmpeg in most cases
[00:55:26 CEST] <kepstin> I think vpxenc can only read raw yuv input :)
[00:55:39 CEST] <TD-Linux> y4m too, but yeah there aren't many tune options
[01:00:20 CEST] <kyleogrg> i'll check those out i guess
[01:00:21 CEST] <Mista_D> ny method to use Open GOP and then insert IDR on demand please?
[01:00:27 CEST] <Mista_D> Any *
[01:13:29 CEST] <Mista_D> 'force_key_frames' I-frames are non IDR when used with "x264-params open_gop=1", so are dynamic scene_change frames. Only first frame is IDR in that scenario
[03:31:00 CEST] <MINIMAN10000> Alright so I downloaded 2 480p videos from youtube is there a way to check the quality of it?
[03:46:42 CEST] <MINIMAN10000> does ffmpeg have no reference metrics?
[03:48:08 CEST] <MINIMAN10000> eh screw it ill just use the 720p mp4 as comparison
[03:48:42 CEST] <TD-Linux> not if you don't have a reference.
[03:49:58 CEST] <MINIMAN10000> Mmmm right the higher quality one comes with the added bonus of a different resoluton :|
[03:50:26 CEST] <MINIMAN10000> not sure how to deal with that.
[03:51:28 CEST] <MINIMAN10000> was going to try to print out the psnr comparing the two
[03:53:58 CEST] <TD-Linux> if you don't have to do this repeatedly, I suggest using your eyes as that's what counts in the end anyway
[03:55:46 CEST] <MINIMAN10000> both are 640*480 one is a mp4 at 748 kbps and the other is a 927 webm so I doubted my ability to tell what was better
[03:56:17 CEST] <MINIMAN10000> like what's to say I like the artifacts of a webm but it was objectively worse?
[03:56:17 CEST] <TD-Linux> PSNR is a worse metric than looking at them
[03:56:41 CEST] <TD-Linux> if you can't tell the difference then pick the smaller one
[03:57:51 CEST] <TD-Linux> or pick the webm because it respects your freedoms
[03:58:47 CEST] <MINIMAN10000> maybe if i dumped them both to png or something
[03:59:01 CEST] <MINIMAN10000> I like this plan
[03:59:05 CEST] <TD-Linux> you could write them to y4m and use the daala metric tools
[03:59:09 CEST] <TD-Linux> but that's not the point
[03:59:52 CEST] <TD-Linux> all metrics are worse than looking at it. sure, they'll tell you which is better, but what's the point if you don't agree?
[04:02:13 CEST] <MINIMAN10000> the webm is definately better
[04:02:25 CEST] <MINIMAN10000> it also has a higher bandwidth so I guess this should be of little surprise.
[04:03:25 CEST] <MINIMAN10000> maybe i should encode them myself with a target of 1 mbps in both x264 and vp8
[04:07:41 CEST] <MINIMAN10000> hmm
[04:08:06 CEST] <MINIMAN10000> Pretty sure vp8 is a lot slower than x264 might be worth skipping vp8 altogether
[04:11:47 CEST] <furq> do you mean vp9
[04:12:47 CEST] <MINIMAN10000> Nah I'd skip vp8 for at least vp9
[04:22:14 CEST] <hendry> hi guys, I'm struggling to grok ffprobe to just give me the video stream info. Specifically looking at DAR (aspect ratio) for i in *; do ffprobe $i 2>&1 | tee /dev/stderr | grep Stream; done
[04:22:30 CEST] <hendry> What am I missing?! http://s.natalian.org/2016-08-31/1472610141_2548x1380.png
[04:26:49 CEST] <furq> hendry: -show_streams -show_entries stream=display_aspect_ratio
[04:28:11 CEST] <hendry> furq: the stdout/stderr i find more confusing since grep doesn't appear to want to work with it
[04:30:48 CEST] <furq> log messages go to stderr
[04:31:18 CEST] <furq> if you don't specify -show_format/-show_streams/etc then only log messages will be shown
[04:31:52 CEST] <furq> but -show_streams goes to stdout so you shouldn't need to bother redirecting stderr
[04:40:25 CEST] <hendry> i ended up with http://s.natalian.org/2016-08-31/check-aspect-ratio.sh
[04:42:08 CEST] <furq> http://vpaste.net/DVI0V
[04:42:11 CEST] <furq> that should be all you need
[04:42:43 CEST] <furq> also it's probably worth mentioning that dar won't always be explicitly set
[04:48:15 CEST] <hendry> furq: thanks
[06:20:58 CEST] <manusitara> Hi All
[06:21:01 CEST] <manusitara> How can I extract the count of particular macro block types(I, P and S) from the frames in the video (H.264 and MP4)? Also, I would like to extract the prediction residual of each of the P and B frames (computed from its corresponding reference frame) in the video from the encoded version itself while the package is decoding it.
[06:59:00 CEST] <ricemuffinball> x265 2.0:[Windows][GCC 5.4.0][64 bit] 8bit
[06:59:00 CEST] <ricemuffinball> Encoding settings              : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=3 / subme=3 / merange=57 / no-rect / no-amp / max-merge=3 / temporal-mvp / no-early-skip / rskip / rdpenalty=0 / no-tskip / no-tskip-fast / no-strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers /
[06:59:00 CEST] <ricemuffinball> interlace=0 / keyint=300 / min-keyint=30 / scenecut=40 / rc-lookahead=25 / lookahead-slices=0 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=4 / limit-refs=3 / limit-modes / weightp / no-weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=4 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid
[06:59:00 CEST] <ricemuffinball> / cutree / no-intra-refresh / rc=crf / crf=21.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30
[06:59:00 CEST] <ricemuffinball> Default                        : Yes
[07:32:31 CEST] <manusitara> How can I extract the count of particular macro block types(I, P and S) from the frames in the video (H.264 and MP4)? Also, I would like to extract the prediction residual of each of the P and B frames (computed from its corresponding reference frame) in the video from the encoded version itself while the package is decoding it.
[08:13:38 CEST] <Kadigan> JEEB: did You have a chance to take a look at the xd5c issue? In the meantime I installed ffmbc with homebrew (forgot I had it), but it would still be good to use ffmpeg, because ffmbc runs a much older build I believe...
[08:16:23 CEST] <BigWoop> Is it possible to loop a gif as a watermark into a existing video file?
[09:37:58 CEST] <Kadigan_KSB> JEEB: I'm not sure if You replied, and it seems my router (or something...) died on the remote end. Did You reply?
[09:56:06 CEST] <JEEB> Kadigan_KSB: no. I will look at it as I have time and so forth outside of my work which is quite busy as well :P
[10:09:59 CEST] <Kadigan_KSB> JEEB: I'm just checking in, is all.
[10:32:28 CEST] <mdoe> Hello channel. I'm using ffmpeg on a rpi to rencode a high bitrate QuickSyncVideo source, but I have a slight problem. The problem being that a QSV source is aroudn 15fps slower than a software encoded x264 source, is there any reason for that?
[10:33:14 CEST] <mdoe> Comparing the two outputs from OBS, i can only find the following differences http://imgur.com/a/3mGNu
[10:59:00 CEST] <manusitara> Hi
[10:59:03 CEST] <manusitara> How can I extract the count of particular macro block types(I, P and S) from the frames in the video (H.264 and MP4)?
[10:59:03 CEST] <manusitara> Also, I would like to extract the prediction residual of each of the P and B frames (computed from its corresponding reference frame) in the video from the encoded version itself while the package is decoding it.
[11:01:57 CEST] <nonex86> *whispering* what about https://www.itu.int/rec/T-REC-H.264 ?
[11:19:33 CEST] <k_sze_> If I follow this guide and compile ffmpeg on Ubuntu 14.04 64-bit: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
[11:19:43 CEST] <k_sze_> Do I automatically get a 64-bit version of ffmpeg?
[11:20:09 CEST] <k_sze_> because I see that it outputs a bunch of files under */x86/*
[11:30:39 CEST] <k_sze> And make is still outputting hevc stuff even though I haven't enabled x265 in the ./configure flags. odd.
[11:31:56 CEST] <furq> the hevc decoder is builtin
[11:37:56 CEST] <k_sze> ah
[11:42:27 CEST] <patters> Hi, I'd like to report a fairly long-standing GPL violation by Synology the maker of NAS appliances. They have not published sources since August last year, and they use FFmpeg in their product.
[11:43:14 CEST] <patters> I have reported it to GPL Violations months ago but nothing has happened, and I have also raised support requests with Synology and alerted their forum users.
[11:43:29 CEST] <patters> However, I think some heavier shaming on FFmpeg's website might be necessary
[11:45:25 CEST] <Kuukunen> automated weekly shame e-mails
[11:49:58 CEST] <patters> How does that work? FFmpeg sends them out to the companies concerned?
[11:55:32 CEST] <relaxed> patters: file the violation on ffmpeg's bug tracker
[11:57:10 CEST] <patters> OK, will do thanks
[13:02:32 CEST] <robin__> Hi there
[13:07:42 CEST] <Spring> how can I check which settings are disabled when using a different h.264 Profile?
[13:08:21 CEST] <furq> Spring: https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Feature_support_in_particular_profiles
[13:09:01 CEST] <robin__> i've installed ffmpeg on ubuntu 14.04 and running simple video capture command but writing into file. The output.mkv file is showing black screen nothing captured
[13:09:08 CEST] <robin__> how to fix?
[13:09:13 CEST] <Spring> furq, I honestly have no idea if those affect my settings
[13:10:27 CEST] <robin__> anyone?
[13:11:40 CEST] <Spring> furq, do you know if these setting would be okay with profile 3.1? http://pastebin.com/QMZSrZrL
[13:11:47 CEST] <Spring> *settings
[13:11:56 CEST] <furq> 3.1 is a level, not a profile
[13:12:08 CEST] <robin__> furq?
[13:12:19 CEST] <Spring> baseline 3.1, sorry
[13:12:39 CEST] <furq> probably not
[13:12:40 CEST] <Spring> er, actually Main, from what I've read
[13:12:58 CEST] <furq> 1080p30 is too much for level 3.1
[13:13:10 CEST] <furq> you'd need 4.1 for that
[13:13:21 CEST] <Spring> oh, so it's resolution based, even with Main 3.1?
[13:13:33 CEST] <furq> levels and profiles are distinct
[13:14:01 CEST] <furq> you can force a profile with -profile:v, that'll restrict the encoder to use the specified feature set
[13:14:19 CEST] <furq> but the level is based on the data rate
[13:14:48 CEST] <furq> there is a -level:v option but it seems less than useless with x264
[13:15:09 CEST] <Spring> basically looking at this site's requirements, and it states 'Main 3.1 or lower' is required. Yet they list 4K 60FPS among the accepted resolutions/fps: http://blog.streamable.com/stream-copy-by-streamable
[13:15:22 CEST] <furq> they probably don't know what they're talking about then
[13:15:29 CEST] <Spring> Lame
[13:15:32 CEST] <furq> well, they definitely don't
[13:15:43 CEST] <furq> 2160p60 requires level 5.2
[13:15:59 CEST] <Spring> I should email them
[13:18:36 CEST] <furq> you can have ffmpeg create a 2160p60 file which says it's level 3.1 in the header
[13:18:56 CEST] <furq> but that will probably do more harm than good
[13:28:18 CEST] <Spring> I've shot them an email to see if they can clarify if they actually check this stuff
[13:28:33 CEST] <Spring> as well as pointing out the issues
[13:32:59 CEST] <Spring> I also don't understand why there's a limit between 30fps and 30fps when it doesn't affect the filesize
[13:33:09 CEST] <Spring> on that site page that is
[13:33:16 CEST] <Spring> *and 60fps
[13:37:11 CEST] <furq> it would make sense if those bitrate values weren't pulled out of thin air
[13:39:03 CEST] <furq> and also if they hadn't already said the nonsense about level 3.1
[13:53:31 CEST] <robin__> anyone there
[13:53:44 CEST] <robin__> i've installed ffmpeg on ubuntu 14.04 and running simple video capture command but writing into file. The output.mkv file is showing black screen nothing captured
[13:57:36 CEST] <durandal_1707> robin__: pastebin full ffmpeg command output
[14:31:48 CEST] <robin__> @durandal_1707 : here is the output log of ffmpeg
[14:31:49 CEST] <robin__> http://pastebin.com/HezVgMg3
[14:34:28 CEST] <robin__> any idea brother?
[14:40:41 CEST] <durandal_1707> robin__: add "-pix_fmt yuv420p" its written there
[14:40:55 CEST] <robin__> ok let me check
[14:45:40 CEST] <robin__> durandal_1707 : Option pixel_format not found
[14:50:25 CEST] <durandal_1707> robin__: where you put it? order matters in ffmpeg
[14:50:43 CEST] <robin__> oh
[14:51:03 CEST] <robin__> after resolution param
[14:51:42 CEST] <robin__> ffmpeg -f x11grab -s 361x176 -pix_fmt yuv420p
[14:51:43 CEST] <durandal_1707> robin__: put it after -vcodec libx264
[14:51:47 CEST] <robin__> ok
[14:52:00 CEST] <durandal_1707> robin__: actually just before
[14:52:38 CEST] <furq> ?
[14:52:44 CEST] <furq> does that make any difference
[14:55:53 CEST] <durandal_1707> yes
[14:56:59 CEST] <robin__> Error while opening encoder for output stream #0.0 - maybe incorrect parameters such as bitrate, rate
[14:58:34 CEST] <durandal_1707> robin__: paste full command you tried
[15:01:40 CEST] <robin__> ffmpeg -f x11grab -s 361x176 -i :0.0 -r 25 -pix_fmt yuv420p -vcodec libx264 /home/user/Videos/output.mkv
[15:03:43 CEST] <Spring> anyone know what Handbrake's 'Fast Decode' x264 option enables?
[15:04:10 CEST] <Spring> The description simply says it optimizes for 'faster decoding' but doesn't list the actual option it changes/adds
[15:04:19 CEST] <furq> it's --tune fastdecode
[15:04:32 CEST] <furq> which iirc disables cabac and deblocking
[15:04:40 CEST] <furq> you almost certainly don't want to enable that
[15:04:55 CEST] <JEEB> unless you're encoding for the original Xbox or something :)
[15:05:13 CEST] <JEEB> (733MHz P3 era Celeron without any HW decoders)
[15:05:17 CEST] <Spring> I see. It's in the Handbrake UI as a separate checkbox than the other Tune settings so I wondered
[15:05:33 CEST] <furq> maybe it's something different, i'm just assuming that handbrake makes some kind of logical sense
[15:05:40 CEST] <furq> i can't imagine what else it'd be
[15:06:04 CEST] <Spring> actually, it's also listed in the Tune drop-down, so that must be it
[15:07:14 CEST] <robin__> @durandal_1707 : ffmpeg -f x11grab -s 361x176 -i :0.0 -r 25 -pix_fmt yuv420p -vcodec libx264 /home/user/Videos/output.mkv
[15:07:38 CEST] <furq> apparently it's --no-cabac --no-deblock --no-weightb --weightp 0
[15:07:50 CEST] <furq> i was close
[15:08:53 CEST] <durandal_1707> robin__: ffmpeg -f x11grab -s 361x176 -framerate 25 -i :0.0 -pix_fmt yuv420p -vcodec libx264 /home/user/Videos/output.mkv
[15:25:49 CEST] <robin__> @durandal_1707 : Same error
[15:27:12 CEST] <durandal_1707> robin__: pastebin full ffmpeg command line
[15:31:16 CEST] <robin__> @durandal : http://pastebin.com/H2cnvKbv
[15:39:48 CEST] <robin__> @durandal any hopes?
[15:41:29 CEST] <c_14> robin__: pick a width that's divisible by 2 (e.g. 362)
[15:47:40 CEST] <robin__> c_14  : Its working now but still black screen
[15:47:49 CEST] <c_14> robin__: do you have more than 1 physical monitor?
[15:47:53 CEST] <robin__> no
[15:48:12 CEST] <robin__> i'm running in inside a virtualBox
[15:48:16 CEST] <robin__> it*
[15:48:29 CEST] <c_14> Is the upper left corner of the screen black?
[15:48:31 CEST] <robin__> ubuntu is running under windows
[15:48:35 CEST] <robin__> no its all black
[15:48:39 CEST] <durandal_1707> robin__: cant you read, it says width not divisible by 2
[15:48:47 CEST] <robin__> @durandal its fixed
[15:48:54 CEST] <robin__> but still black screen issue
[15:48:57 CEST] <c_14> robin__: not the video, the display
[15:49:12 CEST] <robin__> yes i have just on laptop screen.
[15:49:15 CEST] <c_14> Because if you're recording something black, and it ends up black that's expected.
[15:49:16 CEST] <robin__> one*
[15:49:23 CEST] <robin__> no
[15:49:48 CEST] <durandal_1707> robin__: do you have ffplay installed?
[15:49:49 CEST] <robin__> i'm browsing moving my windows hoping around
[15:50:06 CEST] <robin__> umm i think no
[15:50:17 CEST] <robin__> i installed ffmpeg from apt-get
[15:50:50 CEST] <durandal_1707> run ffplay /home/user/Videos/output.mkv
[15:50:55 CEST] <robin__> ok
[15:52:13 CEST] <robin__> yes i have ffplay and its same black screen
[15:54:33 CEST] <radia> Why do I always end up with a large webm file? How do I keep it under 10 MB, what am I doing wrong? I am using this command: ffmpeg -i input.mp4 -ss 00:00:00.00 -t 00:00:25.0 -c:v libvpx-vp9 -metadata title="Untitled" -pass 2 -qmin 0 -qmax 50 -b:v 1000K -c:a libvorbis -b:a 64K -vbr on -threads 1 -speed 1 -tile-columns 0 -frame-parallel 0 -auto-alt-ref 1 -lag-in-frames 25 -g 64 -aq-mode 0 -sn
[15:54:34 CEST] <radia> -f webm output.webm
[15:55:25 CEST] <durandal_1707> robin__: how is your Xorg setup?
[15:55:26 CEST] <nonex86> can anyone advise the easiest way how to fill up avaudiofifo with silence?
[15:56:14 CEST] <Spring> radia, you're doing two passes?
[15:59:22 CEST] <robin__> @durandal: Xorg setup?
[16:00:43 CEST] <robin__> running under virtualBox : 14.04 gnome
[16:00:52 CEST] <durandal_1707> nonex86: av_samples_set_silence after you allocate AVFrame .....
[16:01:04 CEST] <nonex86> yeah, thanks, already found it :)
[16:03:07 CEST] <nonex86> also av_samples_alloc calls av_samples_set_silence internaly
[16:03:16 CEST] <nonex86> thats exactly what i want :)
[16:05:54 CEST] <gauthier> Hi all. I'm trying to write the smallest program I can that outputs an mpg file. I'm slowly getting there, maybe, I think, I hope. I get a warning: "VBV buffer size not set, using default size of 130KB"
[16:06:20 CEST] <gauthier> I guess it's the muxer who wants that, but I'm not sure how and where to set it?
[16:17:48 CEST] <robin__> @durandal: any hopes?
[16:18:13 CEST] <durandal_1707> robin__: i dont have virtualbox
[16:54:17 CEST] <Spring> so I'm testing Handbrake and using the same settings as ffmpeg getting faster encodes. Any idea if Handbrake is utilizing something ffmpeg isn't?
[16:55:29 CEST] <c_14> It might automatically be using hardware accelerated decoding
[16:55:46 CEST] <Spring> is there a way to enable that in ffmpeg?
[16:56:49 CEST] <c_14> the -hwaccel input option
[16:56:51 CEST] <Spring> wait, decoding or encoding?
[16:56:58 CEST] <c_14> decoding
[16:58:41 CEST] <Spring> if no supported hardware is found will it simply not be used or throw an error?
[16:59:17 CEST] <c_14> >This option has no effect if the selected hwaccel is not available or not supported by the chosen decoder.
[16:59:24 CEST] <c_14> Not sure if/how much faster it would be though
[16:59:41 CEST] <c_14> probably depends on if you're encoding faster or slower than realtime
[17:00:59 CEST] <Spring> does the option always need a value or will it find the appropriate hardware automatically?
[17:01:00 CEST] <furq> i don't think it does hardware decoding unless you enable it
[17:02:07 CEST] <furq> iirc handbrake defaults to vfr output so that could be it
[17:03:47 CEST] <jkqxz> Hardware decode on Intel is stupidly fast (like 1000fps at 1080p), but if you are doing anything but the lowest-complexity encode that doesn't make much difference because the encode completely dominates the time.
[17:04:37 CEST] <furq> it wouldn't surprise me that much if handbrake was better optimised than the ffmpeg cli
[17:04:50 CEST] <jkqxz> The encoding options being subtly different seems like a more likely explanation to me.
[17:04:54 CEST] <furq> or that
[17:07:02 CEST] <Spring> I'm setting the same maxrate, bufsize, CRF, Tune, Preset. When you mention variable framerate, how would that affect the encode? Does it change the input framerate?
[17:07:48 CEST] <Spring> the Handbrake setting merely states Framerate: Same as source, with Variable Framerate enabled by default.
[17:27:21 CEST] <zeryx> hey guys, I have a somewhat complex question
[17:28:09 CEST] <zeryx> my first process is to split a video file into subvideos on keyframes, that part works, however the duration of each subvideo is variable (ofc because the keyframes aren't uniform on every video stream).
[17:28:42 CEST] <zeryx> my second process splits each of those subvideos into frames with a particular -fps, it then orders them and outputs a list of frames in order
[17:31:45 CEST] <blue-jaypeg> I have a question about repositories-- I am following the compile instructions from trac.ffmpeg.org-- install dependencies.  Got the following message. " Unable to locate package  libsdl1.2-dev
[17:31:45 CEST] <blue-jaypeg> E: Couldn't find any package by glob ' libsdl1.2-dev'
[17:31:45 CEST] <blue-jaypeg> E: Couldn't find any package by regex ' libsdl1.2-dev'
[17:31:45 CEST] <blue-jaypeg> E: Unable to locate package  libxcb-xfixes0-dev"
[17:32:56 CEST] <blue-jaypeg> How do I locate missing files libsdl1.2-dev and libxcb-xfixes0-dev?
[17:42:57 CEST] <zeryx> the split to frames operation doesn't maintain a steady fps throughout the whole splitting process
[17:43:25 CEST] <zeryx> what would be the best approach to maintain a specific fps even if the subvideos are not aware of eachother (IE they are split on different computers)
[17:43:53 CEST] <zeryx> blue-jaypeg: check your LD_LIBRARY_PATH system variable
[17:57:13 CEST] <blue-jaypeg> Zeryz:  I ran ldconfig -v and I did not see libxcb-xfixes0-dev or  libsdl1.2-dev.  What am I looking for?
[17:57:27 CEST] <furq> what distro are you on
[18:09:25 CEST] <Weedlol> l
[18:15:27 CEST] <mcjack> Hi everybody! I want to use ffmpeg as reader for an audio toolkit juce.com, so I have to compile with C++11
[18:15:57 CEST] <mcjack> however, I get an error in timestamp.h line 46:
[18:16:13 CEST] <mcjack> snprintf(buf, AV_TS_MAX_STRING_SIZE, "%"PRId64, ts);
[18:16:41 CEST] <durandal_1707> mcjack: error is?
[18:16:51 CEST] <mcjack> In file included from ../../../../FsPro_modules/fspro_ffmpeg/fspro_ffmpeg_FFmpegVideoComponent.cpp:26:
[18:16:52 CEST] <mcjack> ../../../../lib/build/darwin/include/libavutil/timestamp.h:46:71: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal]
[18:16:52 CEST] <mcjack>     else                      snprintf(buf, AV_TS_MAX_STRING_SIZE, "%"PRId64, ts);
[18:17:10 CEST] <mcjack> sorry, not a fast typer ;-)
[18:17:56 CEST] <mcjack> So should C++11 be supported?
[18:19:25 CEST] <mcjack> PRId64 is defined here:
[18:19:36 CEST] <mcjack> #  define PRId64        __PRI_64_LENGTH_MODIFIER__ "d"
[18:20:22 CEST] <mcjack> from OSX 10.11: usr/include/inittypes.h
[18:21:15 CEST] <jkqxz> Hmm.  Building as C++ is not really supported.  That one might be worth fixing if it's the only problem, though.
[18:21:31 CEST] <jkqxz> Can you get around it by adding -Wno-reserved-user-defined-literal to the compile line?
[18:21:57 CEST] <mcjack> I don't know that syntax, shall I simply add a space as the compiler proposes?
[18:23:09 CEST] <mcjack> Sorry, I should have checked before& yes adding a space makes it compile
[18:23:30 CEST] <jkqxz> Yes, that will get around that specific problem.
[18:24:47 CEST] <mcjack> Ok, thanks for confirming this. and sorry for the noise
[18:41:51 CEST] <mcjack> jkqxz: -Wno-reserved-user-defined-literal works as well, so no need to modify the source& thanks once more
[19:10:27 CEST] <zeryx> how can I split video into frames with a defined fps, when that video is split into subvideos using -segment 1 first?
[19:10:50 CEST] <zeryx> IE is there a way to force the video splitting into subvideos to be of consistent duration?
[19:13:27 CEST] <zeryx> I suppose I could define the timestamps to create a image frame of in advance, and then pass that to the subvideos to know when to split, but that's a bit convoluted
[20:27:27 CEST] <Jnorthrup> is there a fix for 1485 clean aperture for the 'tapt' chunks in MOV format?
[20:27:46 CEST] <Jnorthrup> do we have to dump the chunk and run a scale filter ?
[20:28:13 CEST] <Jnorthrup> grep the dimensions from ffprobe or whatever to crop and resize?
[20:29:19 CEST] <kepstin> as far as I know, ffmpeg doesn't have any handling for clean aperture in any format
[20:30:49 CEST] <Jnorthrup> ok, so, yes?  crack the chunk and decypher mode and rectangle....
[20:31:15 CEST] <Jnorthrup> lavf is writing tapt chunks, its not impressive what is does.
[20:31:19 CEST] <kepstin> (doesn't help that most containers don't store the information, so you're expected to know it based on media specs of what you're working with)
[20:33:39 CEST] <Jnorthrup> "most containers" ? you mean like any MOV muxer !(quicktime >7 )
[20:34:10 CEST] <kepstin> as far as I know, mov is the only one, yes ;)
[20:34:23 CEST] <kepstin> the "correct" way to handle it in ffmpeg would probably be to interpret the clean aperture size data and attach it as metadata to the stream, where you could then have e.g. a 'crop-to-aperture' filter or something that uses the data, and the ability to re-encode it back into the output file.
[20:36:14 CEST] <Jnorthrup> there is no crop-to-aperture filter to date right? i've seen scale with lancosz in the ancient dead forum posts
[20:36:51 CEST] <Jnorthrup> im actulally coding 720x468 ->720x468 and bringing in the full rasters to the ffmpeg output.
[20:37:46 CEST] <Jnorthrup> but its sdi interlaced source so the rasters are jagged and meandering on the black edges.
[20:38:03 CEST] <kepstin> fun. ntsc stuff? clean aperture on that is normally considered to be the center 704x480, but different standards start on different lines and take a different 480px :/
[20:38:30 CEST] <Jnorthrup> yes ntsc
[20:46:05 CEST] <kepstin> if Jnorthrup was still here, I'd say: assuming you want to follow the smpte rp-202 spec (mpeg digital video), crop=704:480:5:8 should give you the correct clean aperture, if it's field-1-dominant capture then that'll be tff interlaced.
[20:57:51 CEST] <kepstin> (if you're working with DV stuff, you should of course use crop=704:480:4:8 and the opposite field will be at the top)
[22:51:07 CEST] <Guest15129> hello
[22:52:25 CEST] <Guest15129> I have a problem with compiling ffmpeg from source
[22:52:34 CEST] <Guest15129> i am a noob...
[22:53:28 CEST] <Guest15129> apparently debian, in their great wisdom, has lied to me about ffmpeg and so i have removed the libav stuff, and trying to get ffmpeg on
[22:53:40 CEST] <Guest15129> it is a raspberry pi 2b
[22:54:02 CEST] <Guest15129> ERROR: libfdk_aac not found
[22:54:06 CEST] Action: llogan prods relaxed for his arm builds
[22:54:23 CEST] <Guest15129> also, had problem with the 265
[22:55:01 CEST] <Guest15129> it is running raspbian
[22:55:35 CEST] <BtbN> x265 on a Pi sounds fun.
[22:55:38 CEST] <llogan> debian testing and sid now provide ffmpeg
[22:55:57 CEST] <Guest15129> ooh
[22:56:09 CEST] <Guest15129> i had hoped there will be an easier way than compiling
[22:56:34 CEST] <llogan> are you cross compiling or compiling on the rpi itself?
[22:56:39 CEST] <Guest15129> i dont know if i need 265 or not, like i said i am a noob
[22:56:45 CEST] <Guest15129> i was doing it on the pi
[22:57:05 CEST] <Guest15129> i followed the tutorial for installing , from the ffmpeg website
[22:57:23 CEST] <llogan> you only need it if you want to use it to encode H.265 video, but it is probably too underpowered to be of any use on that device...i guess.
[22:57:24 CEST] <furq> if you can use regular debian repos with raspbian then you can just install it from there
[22:57:38 CEST] <furq> although you'll probably want to compile it yourself so you can use the omx encoder
[22:57:43 CEST] <kepstin> I mean, you usually don't even want to run x264 on a pi, given how slow they are, let alone x265 :/
[22:58:19 CEST] <Guest15129> well, for my purpose, what it is for is i am planning to make a small robot which will "see" things and hear things, and react appropriately
[22:58:53 CEST] <Guest15129> i heard from some other folks tutorials, that ffmpeg is a great tool for this
[22:59:08 CEST] <kepstin> (although the latest model with the quad-core A53 might be almost ok)
[22:59:21 CEST] <Guest15129> the pi 3 is in the mail ;)
[22:59:27 CEST] <Guest15129> but i couldnt wait to start
[22:59:36 CEST] <furq> well for starters, raspbian sucks
[22:59:43 CEST] <furq> you can just run regular debian on the pi 2 and 3
[22:59:53 CEST] <furq> so when it shows up, do that
[23:00:00 CEST] <Guest15129> nice
[23:00:04 CEST] <kepstin> regarding that sort of video analysis/processing, you probably don't want to do any video encoding at all, it should just be raw video frames all the way through
[23:00:16 CEST] <kepstin> probably want to look at opencv
[23:00:22 CEST] <Guest15129> so, you saying to take snapshots and analyze
[23:00:33 CEST] <kepstin> although I dunno how the camera's hooked up, you might need ffmpeg to change video formats or something.
[23:00:33 CEST] <Guest15129> that was my plan
[23:00:40 CEST] <furq> i mean it depends what format comes off your camera
[23:00:46 CEST] <Guest15129> but i like the idea to be able to stream stuff
[23:00:56 CEST] <Guest15129> well, it is an old piece of ...
[23:01:02 CEST] <furq> that's probably good tbh
[23:01:02 CEST] <Guest15129> i plan to get a new camera
[23:01:16 CEST] <Guest15129> or i may buy the pi camera module
[23:01:28 CEST] <kepstin> a typical usb webcam will either return raw yuv images (SD resolutions) or mjpeg (HD resolutions).
[23:01:35 CEST] <Guest15129> but i just bought this roomba, and a new pi, so i dont want my girlfriend to be mad..
[23:02:46 CEST] <llogan> you can always get a new girlfriend
[23:02:58 CEST] <Guest15129> lol
[23:03:10 CEST] <Guest15129> but she cooks...
[23:03:20 CEST] <furq> you can just drink soylent
[23:04:52 CEST] <Guest15129> well thanks for the advices, when my new pi comes in on tuesday, i will try Sid on it
[23:05:15 CEST] <Guest15129> i rather do not really like raspbian that much anyway
[23:05:57 CEST] <llogan> there's also Arch Linux ARM
[23:06:39 CEST] <Guest15129> llogan, i thought about that, i have more experience with debian (even though, that's not saying much, lol)
[23:06:49 CEST] <llogan> arch arm has ffmpeg 3.1.3 and opencv 3.1.0
[23:07:29 CEST] <Guest15129> that's cool. from what i read, the arch has it easy to install, unlike debian which lied to me
[23:16:48 CEST] <Jnorthrup> can i use ffprobe to dump the tapt chunks?
[23:17:08 CEST] <Jnorthrup> that would suck less than dusting off my box parser
[23:30:01 CEST] <kepstin> Jnorthrup: if you're just dealing with ntsc stuff, I wouldn't bother.
[23:30:04 CEST] <kepstin> Jnorthrup: assuming you want to follow the smpte rp-202 spec (mpeg digital video), crop=704:480:5:8 should give you the correct clean aperture, if it's field-1-dominant capture then that'll be tff interlaced.
[23:30:38 CEST] <kepstin> (then scale to 640x480 to get square pixels, if you like)
[23:30:53 CEST] <Jnorthrup> right.  love that.
[23:32:23 CEST] <Jnorthrup> http://standards.globalspec.com/std/1092124/smpte-rp-202 ....
[23:33:07 CEST] <kepstin> Jnorthrup: behind a paywall, yeah. I've looked up other references that quote it to get the correct values :)
[23:35:23 CEST] <kepstin> oh, great, I got the offsets backwards
[23:35:33 CEST] <kepstin>  I of course meant crop=704:480:8:5 :)
[23:35:41 CEST] <kepstin> horizontal then vertical...
[23:38:26 CEST] <Jnorthrup> i actually have non-aperture 720 486 mixed with the quicktime aperture stuff
[23:39:06 CEST] <Jnorthrup> im thinking i should key off  the presence of tapt if not the w,h int32's in the clef chunks
[23:39:42 CEST] <Jnorthrup> trying to find a tool i didnt write for a commercial client to read box atoms and dump them
[23:40:16 CEST] <Jnorthrup> gpac appears pre- tapt
[23:40:24 CEST] <Jnorthrup> mp4box
[23:42:35 CEST] <kepstin> that crop I gave will work on all 720x486 stuff.
[23:43:16 CEST] <kepstin> (if you have 720x480 stuff, it's probably already using that same vertical section, unless it was from DV in which case it'll be one line off)
[23:43:30 CEST] <Jnorthrup> so the bug im fixing happens on a 720x486 peice of media without aperture, the transcoders in play hardcode the aprture correction on the geometry
[23:44:02 CEST] <Jnorthrup> your suggestion is exactly the problem
[23:45:01 CEST] <JEEB> Jnorthrup: l-smash's boxdumper btw, for dumping structure of a mov-based file
[23:45:17 CEST] <JEEB> https://github.com/l-smash/l-smash
[23:45:26 CEST] <kepstin> if your 720x486 stuff contains the correct video lines according to the SDI specification (which it almost certainly does), my crop will grab the correct video lines to use for '480 line' digital video encoding
[23:45:44 CEST] <JEEB> very little dependencies and should do exactly what it says on the tin
[23:45:51 CEST] <Jnorthrup> mp4box in.mov  -std -diso   looks like enough for xpath
[23:45:52 CEST] <kepstin> (and you always crop the width to 704px wide, centered)
[23:46:33 CEST] <kepstin> with NTSC video, the lines corresponding to the "actual video area" were never really all that accurate anyways :/
[23:46:35 CEST] <JEEB> which reminds me I should finish up my patches with regards to smooth streaming boxes @ l-smash
[23:48:25 CEST] <kepstin> like, closed captions are actually encoded on what is technically an active video line, but is outside the area most screens show :/
[23:48:26 CEST] <Jnorthrup> http://l-smash.github.io/l-smash/ thanks :) lol
[23:48:46 CEST] <Jnorthrup> i have sdi monitors that show that.
[23:48:55 CEST] <JEEB> yeah, the pages are really barebones :)
[23:50:09 CEST] Action: kepstin wouldn't trust the "clean aperture" values in a file metadata anyways, because who knows if they actually match whatever original source made the video which was encoded into the file anyways
[23:51:03 CEST] <Jnorthrup> well, there seems to be two types of inventory... quicktime prores, and avid prores.
[23:51:37 CEST] <kepstin> like, if the software says the clean aperture is centered on the 486 height but the video contains stuff sourced from an mpeg encoding, you'll have black lines at the top if you use the file aperture.
[23:52:34 CEST] <kepstin> and if the smpte vs dvc specs are confused at some point, you'll have one black line at either the top or the bottom
[23:52:53 CEST] <kepstin> and the only thing you can do is say "meh, that's ntsc for you" and go on.
[23:52:59 CEST] <Jnorthrup> no, we have a third of a black line at the bottom only :P
[23:54:33 CEST] <kepstin> that's why the crop I gave based on the mpeg spec: crop=704:480:8:5 doesn't grab the bottom line from the 486 (it grabs lines (1-based) 5-485) to avoid the "half-line" from ntsc.
[23:54:56 CEST] <kepstin> dv is similar, except it grabs lines 4-484 out of 486
[23:56:25 CEST] <kepstin> you could grab the middle 480 lines to get a properly "centered" clean aperture, but all the mpeg and dv stuff is offset down a bit so you'll get black lines at the top instead :/
[23:56:56 CEST] <kepstin> if your source is VHS then you might as well just give up, it's gonna be horrible no matter what ;)
[23:57:13 CEST] <Jnorthrup> right.  bake a set of transcode permutations and use opencv to check which one looks cleanest when moving head-end transcodes to the broadcast formatss. done.
[00:00:00 CEST] --- Thu Sep  1 2016