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

Tue Apr 25 03:05:02 EEST 2017

[00:48:19 CEST] <jab416171> how can I tell if ffmpeg has support for NVENC?
[00:48:26 CEST] <jab416171> (on my system)
[00:49:51 CEST] <c_14> ffmpeg -encoders | grep nvenc
[00:50:16 CEST] Last message repeated 1 time(s).
[00:50:16 CEST] <jab416171> c_14, thanks!
[00:50:44 CEST] <jab416171> it's there so I guess that means I'm good to go :)
[01:07:38 CEST] <Tatsh> i'm wondering since i've been capturing VHS (NTSC) if i should encode to a lower resolution than what my capture card receives (720x480)
[01:07:51 CEST] <Tatsh> realistically NTSC VHS gives about 423x480
[01:08:46 CEST] <Tatsh> the idea behind encoding close to this resolution is that 'nothing is lost' in the reduction
[01:08:55 CEST] <grublet> VHS in most cases will have nowhere near 480 lines of resolution
[01:08:57 CEST] <Tatsh> since there was no data there (it was interpolated)
[01:09:31 CEST] <Tatsh> well it depends on the source?
[01:09:40 CEST] <Tatsh> my camcorder VHS-C tapes had a decent camera + TBC
[01:09:43 CEST] <grublet> even the highest quality vhs tape still wont have 480 lines
[01:10:13 CEST] <Tatsh> so, like other film, is the true resolution like, dependent on light?
[01:10:21 CEST] <grublet> i personally capture to 352x240 in most cases
[01:10:25 CEST] <Tatsh> the thought of analog 35mm is that it can represent 8K
[01:10:26 CEST] <Tatsh> or better
[01:10:33 CEST] <Tatsh> but only in very good lighting situations
[01:10:35 CEST] <grublet> that depends on multiple things
[01:11:05 CEST] <grublet> but 35mm doesn't have 8k of resolution, that extra resolution is used to more effectively process it later
[01:11:30 CEST] <Tatsh> the video looks 'good' at 240p on its own
[01:11:37 CEST] <Tatsh> but of course upscaling this looks terrible
[01:11:48 CEST] <grublet> capturing at 480 would likely not improve that
[01:11:54 CEST] <grublet> what upscalers have you tried?
[01:11:54 CEST] <Tatsh> but if i save the video at 640x480 (or 422x480), i get some blocky edges
[01:12:11 CEST] <grublet> that depends on what method was used to downsample it
[01:12:38 CEST] <Tatsh> the main thing right now is my capture card saves at 720x480 by default, and then i can do further processing from there
[01:12:45 CEST] <Tatsh> it looks okay with nnedi
[01:13:02 CEST] <Tatsh> meaning, capture size (720x480) or lower looks reasonable
[01:13:07 CEST] <Tatsh> anyone without a reference point won't know
[01:13:18 CEST] <Tatsh> it's just that nnedi is extremely slow
[01:13:52 CEST] <grublet> madvr can do nnedi upscaling on the fly, if you have a gpu that supports it
[01:14:05 CEST] <Tatsh> gtx 980?
[01:14:53 CEST] <grublet> should handle it fine
[01:14:56 CEST] <Tatsh> looks like i'll have to use windows for that
[01:15:01 CEST] <grublet> i use madvr with mpchc on windows
[01:15:09 CEST] <grublet> but if you use linux i think MPV can do similar things
[01:15:12 CEST] <furq> s-vhs is supposed to be 420 lines fwiw
[01:15:39 CEST] <Tatsh> well i'm using a decent VCR, JVC HR-S9900U
[01:15:43 CEST] <grublet> furq: and a solid color can be 8k, but will still have a very low resolution
[01:15:51 CEST] <grublet> at least, it will only exist at DC
[01:15:52 CEST] <Tatsh> it has a TBC built-in, and digital noise reduction with a cache of 4 MB
[01:16:02 CEST] <Tatsh> s-video out
[01:16:10 CEST] <grublet> sounds fancy
[01:16:16 CEST] <Tatsh> it can do wonders on commercial VHS releases
[01:16:22 CEST] <Tatsh> they look like DVD quality
[01:16:57 CEST] <Tatsh> and i'm using a pretty cheap card, Happauge ImpactVCB-e
[01:17:01 CEST] <furq> i'd probably just stick with whatever your capture card puts out
[01:17:22 CEST] <grublet> Tatsh: I am biased because I only ever had cheap TVs and VCRs when I was younger, so I only have that to go by in my own expeirence
[01:17:53 CEST] <grublet> Only had 1 VCR in my life with stereo RCA jacks, and never one that had s-video
[01:17:59 CEST] <furq> JVC keep doing copyright claims on my youtube videos so they obviously suck
[01:18:00 CEST] <Tatsh> the only things that will complain about weird sizes are DVD and blu-ray?
[01:18:23 CEST] <Tatsh> i crop out the overscan crap
[01:18:50 CEST] <Tatsh> for DVD not so much a need, but on blu-ray i prefer to produce a progressive video
[01:19:09 CEST] <grublet> I miss the days of analog video equipment
[01:19:10 CEST] <Tatsh> for DVD, should i make one, the idea is just to leave the video as much intact as possible, including interlacing
[01:19:20 CEST] <Tatsh> the TV/DVD player can do the deinterlacing
[01:19:26 CEST] <Tatsh> Y/C comb filter, etc
[01:19:42 CEST] <furq> having dealt with a lot of badly deinterlaced dvds, i'd say that's for the best
[01:20:03 CEST] <Tatsh> analog stuff is so much fun grublet
[01:20:20 CEST] <Tatsh> except for when belts break, and cleaning heads with isopropyl alcohol
[01:20:24 CEST] <grublet> Tatsh: I agree, i had a lot of fun with my tape recorder as a kid
[01:20:28 CEST] <Tatsh> same here
[01:20:34 CEST] <grublet> record one speed, play back another for low pitch or high pitch voice
[01:20:35 CEST] <Tatsh> my tape deck just broke its belts
[01:20:41 CEST] <furq> don't forget when you leave a player alone for a decade and the belts rot away
[01:20:44 CEST] <Tatsh> yea
[01:20:57 CEST] <Tatsh> i got a belt replacement pack including pinch rollers on ebay
[01:21:02 CEST] <Tatsh> so will be fixed; it's worth it
[01:21:15 CEST] <grublet> furq: but the quality deterioration and imperfections is part of the appeal for analog equipment (for me)
[01:21:15 CEST] <furq> although that's still preferable to finding a direct drive machine has busted a cog and nobody makes them any more
[01:21:25 CEST] <furq> at least belts are generic
[01:21:49 CEST] <Tatsh> if it's a popular hi-fi item, there will be probably be belts on ebay
[01:22:24 CEST] <furq> well even if it's not you can often get the right size of belt cheaply
[01:56:49 CEST] <bencc> how can I install libfdk_aac on ubuntu 17.04?
[01:56:53 CEST] <bencc> I'm getting an error: Unknown encoder 'libfdk_aac'
[01:59:24 CEST] <bencc> I see I can use:
[01:59:24 CEST] <bencc> sudo apt-get install libfdk-aac-dev
[01:59:28 CEST] <bencc> is there a license issue?
[02:00:33 CEST] <furq> yes
[02:00:36 CEST] <furq> it's gpl incompatible
[02:00:44 CEST] <furq> you need to build ffmpeg with fdk yourself if you want it
[02:01:58 CEST] <fiberbaby> please tell me what the difference between static and shared versions of ffmpeg are??
[02:03:05 CEST] <fiberbaby> are->is
[02:03:10 CEST] <bencc> furq: "If your repository provides libfdk-aac-dev then you can install that instead of compiling: "
[02:06:53 CEST] <bencc> furq: what can be the problem if I use libfdk-aac?
[02:08:33 CEST] <furq> there isn't one
[02:08:47 CEST] <furq> it just means you can't distribute the binary without richard stallman coming round to your house and giving you a stern lecture
[02:09:09 CEST] <bencc> I did: sudo apt-get install libfdk-aac-dev
[02:09:15 CEST] <bencc> sudo apt-get install ffmpeg
[02:09:21 CEST] <bencc> it still can't find the codec
[02:09:27 CEST] <furq> 01:00:44 ( furq) you need to build ffmpeg with fdk yourself if you want it
[02:09:28 CEST] <bencc> so the wiki is misslaeding
[02:09:33 CEST] <bencc> https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
[02:09:37 CEST] <furq> it means instead of compiling fdk
[02:09:55 CEST] <bencc> ok
[02:10:32 CEST] <bencc> is there a big difference between libfdk-aac and normal aac?
[02:11:07 CEST] <furq> fdk can do he-aac
[02:11:27 CEST] <furq> it's probably slightly better at lc-aac but nobody has done a proper test yet
[02:11:42 CEST] <furq> also i believe the builtin aac encoder doesn't do vbr particularly well, but that might be old news
[02:11:51 CEST] <bencc> I'm doing non-live hls
[02:11:59 CEST] <bencc> I guess in my case there shouldn't be too much difference
[02:12:01 CEST] <furq> if you only need cbr lc-aac then it's not really worth bothering
[02:12:33 CEST] <bencc> I'm using '-c:a aac -b:a 96k'
[02:12:46 CEST] <bencc> assuming it's good settings
[03:32:11 CEST] <ZexaronS> spammers sending me javasript code
[03:32:28 CEST] <ZexaronS> ZEPHALEIEL and Aventineia
[03:32:33 CEST] <ZexaronS> different nick every time
[03:33:08 CEST] <DHE> you mean in IRC?
[03:33:09 CEST] <ZexaronS> and a link to a website .js
[03:33:19 CEST] <ZexaronS> obviously, if i came to this channe
[03:33:21 CEST] <ZexaronS> channel
[03:33:34 CEST] <DHE> umode +R will block private messages from unregistered users
[03:34:02 CEST] <ZexaronS> IP 91.126.34.83
[03:34:11 CEST] <ZexaronS> 14.186.161.91
[03:34:37 CEST] <ZexaronS> @178.47.143.222
[03:34:42 CEST] <DHE> spain and vietnam
[03:34:46 CEST] <DHE> this is not helping
[03:35:03 CEST] <ZexaronS> I pasted whatever info there is
[03:35:21 CEST] <ZexaronS> the nicks use random generated name each time for every message
[03:35:36 CEST] <ZexaronS> iit cinludes some code and inside the code it's a clicable link to a .js file
[03:36:21 CEST] <DHE> well there's nothing we can do. just ignore it. use the umode assuming you don't need to private message anyone not registered.
[03:36:35 CEST] <ZexaronS> oh okay
[03:36:54 CEST] <ZexaronS> but you can block the ip, no?
[03:37:16 CEST] <ZexaronS> always different one ... but shouldn't it be repeating at some point
[03:38:42 CEST] <DHE> umm, no. first of all, freenode is independently operated and we have no power over that. second it's probably just randomly infected PCs doing this and there's god knows how many of those out there
[03:39:09 CEST] <DHE> seriously, just type "/umode +R" and chances are it will all go away
[03:39:36 CEST] <ZexaronS> Ah, well, I put it on the server window, not sure if it's channel specific or server wide but it should work
[03:40:23 CEST] <DHE> it's a mode on your own user session. it applies outside the context of any channel
[06:22:01 CEST] <johnjay> hmm any idea why this command isn't working?
[06:22:03 CEST] <johnjay> I:\>ffmpeg -i yt.mp4 -vcodec libx264 -f mpegts udp://127.0.0.1:1234
[06:22:13 CEST] <johnjay> It shows video in vlc player but it's jerky and no audio
[08:20:58 CEST] <mbparsa> I was wondering if there is a way to put a 64bit length timestamp value while encoding a raw frame using H.264/H.265. This is important for my application to see exact time of an event?
[08:29:00 CEST] Last message repeated 1 time(s).
[10:07:16 CEST] <bencc> to use "-vf" with multiple outputs (hls) do I have to use -filter_complex and - map?
[10:20:02 CEST] <vlt> Hello. If I want to "extract" a part of an x264 encoded video, is it somehow possible to either use "-ss" and only re-encode the frames up to the next I-frame or "round" the value for "-ss" to the closest or previous one?
[10:20:43 CEST] <vlt> (And then just use "-codec:v copy")
[10:27:55 CEST] <durandal_1707> bencc: yes
[10:36:04 CEST] <bencc> durandal_1707: what if I only need "-s" and " -pix_fmt"
[10:36:06 CEST] <bencc> ?
[10:38:24 CEST] <durandal_1707> if your filtergraph have >1 output you need to use filter complex
[10:40:00 CEST] <bencc> the first example here doesn't use filter_complex
[10:40:00 CEST] <bencc> https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs
[10:40:09 CEST] <bencc> the seocond example
[10:40:18 CEST] <bencc> it just adds "-s 1280x720" ...
[11:24:25 CEST] <superware> I have a problem with the mp4 container, since it writes a trailer containing codec metadata at the end of the file, it is not resistant to unexpected muxing termination (or instable storages), unfinished mp4 are tricky to fix. What's the next recommended output format for h264 video?
[11:25:24 CEST] <JEEB> you can use movie fragments
[11:25:26 CEST] <olspookishmagus> hello, anyone knows the last win32 binary known to be working with WinXP? I'm having troubles with: zeranoe's built ff((mpeg)|(play)|(probe)) binaries, even the older ones: https://pastebin.com/raw/v30dd3cZ
[11:25:27 CEST] <JEEB> in mp4
[11:25:32 CEST] <JEEB> or you can use something like mpeg-ts
[11:25:44 CEST] <superware> JEEB: movie fragments?
[11:25:54 CEST] <JEEB> yes
[11:26:09 CEST] <JEEB> that's the way things are handled in mp4 if you want to be able to play without a full index
[11:26:43 CEST] <BtbN> you can make a mp4 file that's playable without the trailer, but it's not a nice experience
[11:26:58 CEST] <superware> wow
[11:27:08 CEST] <BtbN> Just use mpeg-ts for that usecase
[11:28:08 CEST] <bencoh> +1 for mpeg-ts
[11:30:55 CEST] <JEEB> BtbN: I don't think movie fragments are in any way or form not a nice experience :P
[11:31:03 CEST] <JEEB> but yes, if you need a streaming thing then mpeg-ts
[11:31:25 CEST] <BtbN> JEEB, well, playing such a file results in the player not giving you a duration or a seek bar
[11:34:16 CEST] <JEEB> if mpeg-ts is giving you that I'd rather be saying that's a bug since that's as much a streaming thing. and on file system I've had seeking possible in fragmented isobmff just fine
[11:34:25 CEST] <JEEB> (´4@)
[11:34:34 CEST] <Mavrik> Fragmented MP4 is also less supported than MPEG-TS in my experience.
[11:34:41 CEST] <JEEB> now that is true
[11:34:55 CEST] <JEEB> although that has improved with MPEG-DASH and HLS supporting it
[11:35:35 CEST] <Mavrik> Yeah. The other part is that my heart hurts when I see what a hack it is :P
[11:36:22 CEST] <superware> I found out -movflags faststart, but how should I set it if I use libav directly?
[11:38:54 CEST] <superware> avformat_write_header's options??
[11:39:40 CEST] <JEEB> that doesn't help if things crash during write
[11:39:46 CEST] <JEEB> you need something like frag_keyframe
[11:39:55 CEST] <JEEB> which enables movie fragments
[11:42:28 CEST] <superware> frag_keyframe+faststart ?
[11:53:22 CEST] <JEEB> no
[11:53:25 CEST] <JEEB> faststart isn't needed
[11:53:34 CEST] <JEEB> faststart only works with non-fragmented
[11:53:37 CEST] <JEEB> since it touches moov
[11:54:54 CEST] <BtbN> JEEB, with DASH the needed metadata for seeking and duration is in the manifest. But a plain single fragmented mp4 file does not offer those features.
[11:57:05 CEST] <superware> av_dict_set(&dict, "movflags", "frag_keyframe", 0); avformat_write_header(_output_ctx, &dict); without calling av_write_trailer, but ffplay 20170424_125445.mp4 gives "20170424_125445.mp4: Invalid argument"
[12:00:21 CEST] <superwar> JEEB: sorry, got disconnected
[12:00:46 CEST] <superwar> av_dict_set(&dict, "movflags", "frag_keyframe", 0); avformat_write_header(_output_ctx, &dict); without calling av_write_trailer, but ffplay gives "20170424_125445.mp4: Invalid argument"
[12:39:10 CEST] <olspookishmagus> https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=2477
[12:39:54 CEST] <dongs> haha
[12:40:11 CEST] <dongs> olspookishmagus: time to upgrade to windows 10 creators edition
[12:43:12 CEST] <olspookishmagus> dongs: i'm on work - one would expect someone to have BETTER hardware @ work that being in a production environment and so but I'm a sysadmin somewhere with this: Intel Pentium E6300 @ 2.80GHz, 2,00GB Single-Channel DDR2 @ 398MHz (6-6-6-18)
[12:43:25 CEST] <olspookishmagus> dongs: btw, WHAT's "creators edition"?
[12:43:36 CEST] <dongs> latest win10 update.
[12:43:42 CEST] <dongs> just fixes + updates rolled up together
[12:43:49 CEST] <dongs> and i think 3d mspaint but i dont care about that.
[13:15:07 CEST] <user128> I am wondering how hard will it be to add amr-wb+ support to ffmpeg. someone tried doing so in 2008 (https://ffmpeg.org/pipermail/ffmpeg-devel/2008-December/044239.html) but didn't succeed. I wonder if it is enough to have some C skills or will the port require deep knowledge of the codec itself?
[13:15:50 CEST] <JEEB> if you have the specs it will not be simple but should be possible if you can grasp the basics of how AVCodec works
[13:17:45 CEST] <user128> JEEB, there is reference code available (some initial 3gp parsing parts are binary only though). and ffmpeg already supports amr-wb which is related to amr-wb+.
[13:18:20 CEST] <JEEB> yes
[13:18:29 CEST] <JEEB> so you'd need to know of the format enough to fill the gap
[13:18:40 CEST] <JEEB> definitely not impossible but require at least some understanding of the spec
[13:20:54 CEST] <user128> JEEB, thanks!
[13:21:35 CEST] <user128> http://www.3gpp.org/ftp/specs/archive/26_series/26.304/ -> code for the interested folks. I was able to build it with mingw compiler.
[13:25:57 CEST] <JEEB> we can't necessarily use example code depending on its license
[13:26:19 CEST] <JEEB> so before copying code from somewhere else you have to check if the license is compatible. if it's not then it has to be written from scratch
[13:30:14 CEST] <superware> JEEB: say, should av_dict_set(&dict, "movflags", "frag_keyframe", 0); avformat_write_header(_output_ctx, &dict); be enough for ffplay to later be able to play the mp4 file even if the output terminated unexpectedly?
[13:45:43 CEST] <JEEB> superware: if that sets the flag correctly and you can see moof etc in the output with, say, l-smash's boxdumper --box output
[13:45:47 CEST] <JEEB> then yes
[13:45:58 CEST] <JEEB> (moof is one of the fragmentation related boxes)
[15:16:28 CEST] <bencc> how do I know if I generate AAC-LC, HE-AAC or MP3?
[15:16:39 CEST] <bencc> I'm using "-c:a aac -b:a 128k"
[15:45:27 CEST] <alex88> hi there, https://trac.ffmpeg.org/wiki/ffserver "ffserver is going to be removed by the next release." however seems to be still there in 3.3, is it going to be removed?
[15:46:42 CEST] <Mandevil> bencc: It's not going to generate MP3, that's for sure :)
[15:46:58 CEST] <JEEB> alex88: some people are really adamant on doing the minimal amount of things to supposedly keep it "alive"
[15:47:12 CEST] <JEEB> that was *after* it was decided that it would get removed
[15:47:43 CEST] <JEEB> given that almost nobody knows or recommends ffserver in the team it's really a thing that you're not going to get any support for
[15:48:04 CEST] <alex88> oh ok, I was just wondering why it was still there
[15:48:37 CEST] <alex88> anyway, to create a webcam stream, what's the current solution if not using ffserver?
[15:54:25 CEST] <bencc> I'm trying to use a script that creates several hls variants
[15:54:26 CEST] <bencc> https://github.com/gitfu/manifesto/blob/master/variants.py
[15:54:43 CEST] <bencc> why does the bandwidth doesn't match the maxrate?
[15:55:22 CEST] <bencc> for example for hd1080 it has "abitrate": "128k", "vbitrate": "7800k", "maxrate":"8200k", "bandwidth":7483000
[15:55:40 CEST] <bencc> why bandwidth is 7483000 and not 8200k ?
[16:03:59 CEST] <alex88> anyway, ffserver works perfectly for my use case :D
[16:04:22 CEST] <alex88> spent days dealing with v4l2 encoding and rtsp server and this solved it within minutes
[16:19:27 CEST] <Michaela_> I was wondering if there is a way to put a 64bit length timestamp value while encoding a raw frame using H.264/H.265. This is important for my application to see exact time of an event?
[17:02:02 CEST] <flux> I don't know about h264/h265, but I'm afraid at least MPEG4 container doesn't support 64-bit time stamps. perhaps mkv?
[17:02:24 CEST] <flux> as a special possibility MPEG4's fragment duration is 64-bit, but putting a fragment per frame sounds like a hack
[17:26:48 CEST] <Michaela_> flux
[17:27:08 CEST] <Michaela_> an container is ok as long as they let me encode the timestamp in it
[17:27:17 CEST] <Michaela_> any*
[17:29:38 CEST] <thebombzen> bencc: ffmpeg's aac encoder will generate AAC-LC by default
[17:29:59 CEST] <thebombzen> I"m not entirely sure if it can generate aac, but the way to do that would be -profile:a he_aac
[17:30:29 CEST] <thebombzen> other aac encoders like libfdk_aac might be able to
[17:31:41 CEST] <Michaela_> what is AAC-LC, sorry  I am really new into video
[17:31:50 CEST] <thebombzen> I pinged bencc
[17:31:57 CEST] <thebombzen> means I wasn't talking to you, talking to someone earlier
[17:32:06 CEST] <Michaela_> oh ok :)
[17:32:30 CEST] <thebombzen> Michaela_: it sounds like what you want to do is best done using external information
[17:33:01 CEST] <thebombzen> such as naming your H.264 recording with a filename that contains the timestamp
[17:33:17 CEST] <thebombzen> then when you go and write a program that parses it, it'll take the filename into account.
[17:34:01 CEST] <thebombzen> I'm not entirely use why you're using H.264 to encode one frame at atime though
[18:04:03 CEST] <Michaela_> thebombzen: naming wouldn't work since I need a time stamp each individual frame
[18:04:18 CEST] <thebombzen> well name the file as the timestamp of the first frame
[18:04:30 CEST] <thebombzen> and then the relative timestamps between frames would work
[18:04:51 CEST] <Michaela_> but would that be accurate enough ?
[18:04:59 CEST] <thebombzen> depends on how accurate your grabbing is
[18:05:20 CEST] <thebombzen> it would be perfectly accurate as long as, say, your 30 fps video was 1 frame every 1/30 of a second
[18:05:35 CEST] <thebombzen> how often are you grabbing frames?
[18:05:44 CEST] <Michaela_> so the frames are comming from a a camera
[18:05:48 CEST] <Michaela_> 30 fps
[18:06:13 CEST] <thebombzen> well there you go. if you're receiving 30 frames every second then frame #31 would be 1 second after frame #1
[18:06:15 CEST] <kepstin> so it'll be as accurate as the timing crystal used on your camera, then, basically.
[18:06:38 CEST] <thebombzen> basically. and I don't think you'd get better accuracy by using your computer's clock
[18:06:54 CEST] <thebombzen> because of usb bus delays and stuff
[18:07:21 CEST] <Michaela_> but I probably will need to  encod more than 1 frames , since these are stream i probably need to buffer them for say 100 frames and then encode them using h.264
[18:07:24 CEST] <Michaela_> correct?
[18:07:45 CEST] <thebombzen> why?
[18:07:59 CEST] <Michaela_> to get more out of compression
[18:07:59 CEST] <thebombzen> what are you actually trying to do?
[18:08:08 CEST] <kepstin> Michaela_: it would be helpful if you give us a better idea of your overall requirements
[18:08:19 CEST] <thebombzen> if you're looking to get more out of compression, adding lots of extra frames at the end won't help
[18:08:28 CEST] <thebombzen> it'll help the "compression ratio" but that doesn't matter
[18:09:00 CEST] <Michaela_> So , I have a GigE camera, ethernet interface , with 1280x1024 res , 30 fps
[18:09:42 CEST] <Michaela_> na d I am trying to compress the raw data (YUYV422) coming from camera using h.264
[18:10:00 CEST] <thebombzen> does it have to be h.264?
[18:10:15 CEST] <Michaela_> each frame has a 64 bit timestamp and I would like to keep those timestamp in compressed video
[18:10:15 CEST] <kepstin> it's strange to see an ethernet camera giving raw frames, normally they do on-chip compression
[18:10:52 CEST] <Michaela_> kepstin: yes, keep in mind this is not an IP camera
[18:11:14 CEST] <Michaela_> thebombzen: it does n't have to be, as long as I get a good compression
[18:11:19 CEST] <kepstin> Michaela_: your initial question was an example of the "XY Problem" https://meta.stackexchange.com/a/66378 :)
[18:12:40 CEST] <Michaela_> kepstin: sorry for the confusion :)
[18:12:44 CEST] <kepstin> you're starting with some unusual equipment and have some odd requirements for really accurate timestamps, and we're just not really understanding why you need this or how you're planning to use the data.
[18:13:42 CEST] <Michaela_> so my requirement is to compress the raw data file and also keep the timestamp of each individual frame
[18:13:55 CEST] <Michaela_> the timestamps are 64bit values
[18:14:15 CEST] <kepstin> is this some sort of scientific experiment, and you have a special camera with a very accurate timing source or something like that?
[18:14:49 CEST] <thebombzen> why do you care so much about the timestamps?
[18:14:53 CEST] <Michaela_> yes, the GigE camera can give you nanosecond accuracy of when the image was captured
[18:15:15 CEST] <thebombzen> and if that's the case, is there any reason you can't rely on the video framerate?
[18:15:21 CEST] <kepstin> so you don't want to store 64bit timestamps. you *actually* want to store nanosecond-accurate timestamps?
[18:15:26 CEST] <kepstin> ok, we're getting somewhere now :)
[18:16:00 CEST] <Michaela_> kepstin: that is correct , I was to store the nanosecond-accurate timestamps
[18:16:17 CEST] <thebombzen> matroska can have a timebase of 10^9 but I'm not sure if it's limited to 32-bit timestamps
[18:16:33 CEST] <thebombzen> if so you'd only be able to get ~4 seconds before wraparound
[18:16:46 CEST] <Michaela_> thebombzen: because in a small fraction of time something might  happen so I need to go back to that time and review the video
[18:16:46 CEST] <kepstin> I don't know of anything that writes matroska with a timebase of anything other than milliseconds anyways, ffmpeg's muxer is fixed
[18:17:16 CEST] <kepstin> Michaela_: I suspect what you'll want to do is simply make a log file beside the video that stores the frame number and the exact timestamp of that frame.
[18:17:26 CEST] <thebombzen> kepstin: even if you use -tb:v 1000000000
[18:17:41 CEST] <thebombzen> and Michaela_ it's good to specify. Unix Time is "# of seconds sinced the beginning of 1970" and it's also a 64-bit number
[18:17:54 CEST] <c_14> only on 64-bit systems
[18:17:59 CEST] <thebombzen> which is every system
[18:18:15 CEST] <c_14> I'm sure I can find a 32-bit system
[18:18:24 CEST] <thebombzen> I mean I could too if I searched but the point still stands
[18:18:44 CEST] <Michaela_> thebombzen: is there any API example ?
[18:19:23 CEST] <Michaela_> 64bit is no problem
[18:19:38 CEST] <Michaela_> all of our systems are indeed 64
[18:19:42 CEST] <kepstin> the matroska muxer in ffmpeg (and indeed every other one that I know about) writes with a fixed timebase of 1000. It'll just round any other provided timebase when writing the files
[18:20:28 CEST] <Michaela_> what is fixed timebase of 1000?
[18:20:34 CEST] <kepstin> ogg uses "64bit timestamps" but the way they're structured, I don't think it can do nanosecond accuracy (and it's not good for h264/h265 anyways)
[18:21:39 CEST] <kepstin> Michaela_: frame times in video containers are stored as an integer timestamp per frame, alongside with a fractional (rational) "timebase" value for the entire stream. You get a frame time in seconds by taking the frame timestamp and dividing by the timebase.
[18:21:54 CEST] <thebombzen> what sort of timebases are allowed in nut?
[18:22:34 CEST] <thebombzen> Michaela_: essentially, timestamps in video aren't floats but integers stored in "timebase units"
[18:23:01 CEST] <Michaela_> even microseconds might be ok, worsecase miliseconds
[18:23:11 CEST] <thebombzen> milliseconds is definitely possible
[18:23:19 CEST] <Michaela_> is it?
[18:23:34 CEST] <thebombzen> Matroska's timebase of 1000 means that frames are timestamped in multiples of 1/1000 of a second
[18:23:37 CEST] <thebombzen> i.e. a millisecond
[18:23:52 CEST] <thebombzen> the ffmpeg's matroska muxer has millisecond accuracy on its frames
[18:24:01 CEST] <Michaela_> what is Matroska?
[18:24:10 CEST] <thebombzen> it's a multimedia container
[18:24:18 CEST] <Michaela_> Ah!
[18:24:37 CEST] <kepstin> it looks like the nut container specification allows arbitrary (variable-length) integers to define the timebase. Need to check muxer support :/
[18:24:45 CEST] <thebombzen> things like H.264 are video coding formats. containers like matroska allow you to put several streams together (say, video and audio is usual reason)
[18:25:28 CEST] <thebombzen> kepstin: libavformat might support arbitrary muxer timebases in the muxer
[18:25:37 CEST] <thebombzen> but that doesn't mean ffmpeg.c supports it even if lavf does
[18:25:45 CEST] <Michaela_> thebombzen: so about microseconds or nano, can i put it as a subtitle ?
[18:26:05 CEST] <thebombzen> you wouldn't if you couldn't do it as a video timestamp
[18:26:18 CEST] <thebombzen> subtitles in matroska afaik use the same accuracy as the video
[18:26:38 CEST] <thebombzen> I don't think you could use a text stream to "cheat" and get a finer timebase
[18:26:46 CEST] <Michaela_> so the API might not support matroska?
[18:27:07 CEST] <furq> 17:18:24 ( thebombzen) I mean I could too if I searched but the point still stands
[18:27:08 CEST] <kepstin> thebombzen: ffmpeg.c and libavformat support setting arbitrary timebases, the problem is that some of the containers don't support arbitrary timebases, so they round or convert to a container-supported one
[18:27:12 CEST] <furq> did your search get as far as your pocket
[18:27:24 CEST] <thebombzen> my phone is 64-bit
[18:27:28 CEST] <thebombzen> and embedded systems were not relevant
[18:27:38 CEST] <thebombzen> but anyway, moving back on topic
[18:27:54 CEST] <kepstin> (e.g. mpeg-ts, mpeg-ps have fixed timebase of 90000; matroska format supports arbitrary powers of 10, but I don't think ffmpeg can use anything other than 10^3)
[18:27:56 CEST] <thebombzen> I'll go check to see if the nut muxer supports it
[18:28:03 CEST] <kepstin> nut might work, yeah
[18:28:28 CEST] <Michaela_> is nut also a container?
[18:28:38 CEST] <furq> yes
[18:32:10 CEST] <bencc> thebombzen: thanks
[18:32:20 CEST] <Michaela_> kepstin: so why again mkv is not able to do ?
[18:33:10 CEST] <Michaela_> or why i can't use mkv to perform this task ?
[18:33:52 CEST] <furq> matroska should work in theory but i'm pretty sure ffmpeg always uses a 1/1000 timebase with mkv
[18:34:15 CEST] <thebombzen> furq, we already discussed this
[18:34:27 CEST] <furq> yes you did
[18:34:36 CEST] <Michaela_> so you can't just give 64bit value as a timestamp to mkv->ts?
[18:35:07 CEST] <furq> matroska doesn't have a fixed timebase of 1/1000 though
[18:36:09 CEST] <Michaela_> by 1/1000 you mean miliseconds accuracy ?
[18:36:13 CEST] <furq> yes
[18:36:29 CEST] <Michaela_> so miliseconds accurac is possible using mkv?
[18:37:02 CEST] <furq> with ffmpeg, yes
[18:37:12 CEST] <Michaela_> so I am very new, if I am asking dumb questions :/
[18:37:18 CEST] <furq> nanosecond accuracy is technically possible according to the spec
[18:37:25 CEST] <furq> but i don't know if ffmpeg will let you use anything other than 1/1000
[18:37:39 CEST] <furq> there are dedicated remuxing tools which will set timestamps from timecode files
[18:37:52 CEST] <furq> i know l-smash will let you do that for mp4
[18:38:07 CEST] <Michaela_> fruq: let me conclude here , if i want miliseconds , i should use mkv and it is totally possible using ffmpeg ?
[18:38:17 CEST] <furq> that should just work by default
[18:38:40 CEST] <thebombzen> kepstin: I checked nutenc.c and it appears to just inherit the codec tb
[18:38:51 CEST] <thebombzen> I'm not sure if setting -tb:v will override that
[18:39:06 CEST] <furq> you can set the codec timebase with -x264-params timebase
[18:39:18 CEST] <furq> although it didn't seem to do anything with nut when i just tried it
[18:39:39 CEST] <ritsuka> Michaela_: do you want your timestamps to start from 0 or something else?
[18:39:53 CEST] <furq> also is -tb new in 3.3 or something
[18:39:54 CEST] <furq> i don't have that here
[18:40:18 CEST] <Michaela_> no from a wall time
[18:40:33 CEST] <Michaela_> unit time at the grabbed moment
[18:40:38 CEST] <Michaela_> unix*
[18:41:16 CEST] <furq> are you using v4l2 to capture the camera
[18:41:19 CEST] <thebombzen> it might be -time_base
[18:41:44 CEST] <thebombzen> ah yea it is
[18:41:44 CEST] <Michaela_> nope, Pylon SDk
[18:41:54 CEST] <furq> i don't have that either
[18:41:58 CEST] <thebombzen> so setting -time_base:v 1000000000 just set the timebase to 65536
[18:42:01 CEST] <furq> or at least it doesn't work as an output option
[18:42:23 CEST] <thebombzen> ffmpeg -f lavfi -i yuvtestsrc -c:v libx264 -time_base:v 1000000000 -f nut -y /dev/null
[18:42:26 CEST] <thebombzen> this doesn't work?
[18:42:29 CEST] <furq> no
[18:42:35 CEST] <thebombzen> well I built ffmpeg 5 minutes ago
[18:42:37 CEST] <ritsuka> you could try mov with a timecode track too, but I never tried to write one with ffmpeg so I can't help any further
[18:42:37 CEST] <thebombzen> must be fairly new
[18:42:39 CEST] Action: ritsuka hides
[18:43:20 CEST] <furq> well i assume you can write the timecode track separately
[18:43:52 CEST] <furq> mkvtoolnix and l-smash can both remux with a timecode file
[18:44:14 CEST] <thebombzen> yea. if you need the nanosecond precision that seems like the smartest way
[18:44:17 CEST] <furq> but if ms precision is good enough then i'd have thought this would just work
[18:44:38 CEST] <thebombzen> what sort of data are you recording with the camera that requires such high precision?
[18:44:45 CEST] <thebombzen> it sounds like it's scientific data
[18:45:02 CEST] <thebombzen> and if that's the case, you might want to consider using lossless H.264
[18:45:06 CEST] <thebombzen> if accuracy is *that* important
[18:45:12 CEST] <Michaela_> yes it is , it is brian research
[18:45:25 CEST] <furq> just brians or bryans as well
[18:45:36 CEST] <thebombzen> cause lossless video is unnecessary for humans watching ordinary video
[18:45:37 CEST] <Michaela_> :D
[18:45:48 CEST] <furq> bryans are always getting the short end of the stick
[18:45:55 CEST] <thebombzen> but as a brain scientist you're probably aware that we suck at seeing things accurately
[18:46:07 CEST] <thebombzen> so if you're going to framebyframe it and artifacts really matter, consider using lossless H.264
[18:46:54 CEST] <Michaela_> I know, but since these are from patients with mental disorder, you need to see what happens when something goes wrong
[18:47:39 CEST] <thebombzen> It depends on what you're doing with the video
[18:47:40 CEST] <Michaela_> at the same time space on disk needs to be considered
[18:47:52 CEST] <Michaela_> we need to record for months
[18:47:56 CEST] <thebombzen> oh.
[18:47:57 CEST] <thebombzen> hm.
[18:48:17 CEST] <thebombzen> several months of video in a row? that's going to take up an absurd amount of time
[18:48:18 CEST] <furq> i'd guess you want to consider using yuv444p at least
[18:48:19 CEST] <thebombzen> of space
[18:48:43 CEST] <Michaela_> yuv420p is fine
[18:48:47 CEST] <thebombzen> you sure?
[18:48:54 CEST] <furq> fair enough
[18:48:56 CEST] <thebombzen> yuv420p is a human-eye-focused psychovisual optimization
[18:49:13 CEST] <furq> the scans could be monochrome for all we know
[18:49:26 CEST] <thebombzen> anyway, if you're recording for several months, I'd consider using the segment muxer
[18:49:31 CEST] <Michaela_> eventually I am going to use monochrome
[18:49:46 CEST] <thebombzen> ffmpeg's segment muxer sounds very useful for you here
[18:50:02 CEST] <thebombzen> what it does is instead of recording to a massive file, it'll split the video into several smaller files at keyframes
[18:50:06 CEST] <Michaela_> what's is segment muxer?
[18:50:12 CEST] <furq> !muxer segment
[18:50:12 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c-ssegment
[18:50:12 CEST] <thebombzen> so you could say, write a new file every 24 hours
[18:50:30 CEST] <thebombzen> with a timecoded filename
[18:50:42 CEST] <thebombzen> (although not extremely precise)
[18:51:12 CEST] <Michaela_> oh that is great!
[18:51:12 CEST] <furq> are you using the ffmpeg cli for this
[18:51:25 CEST] <thebombzen> this could solve your hard drive space issue somewhat. if you need to store a massive serveral months long video then you'll run out of space
[18:51:27 CEST] <Michaela_> no, I have to stick with API
[18:51:29 CEST] <furq> oh ok
[18:51:31 CEST] <furq> that's fine then
[18:51:45 CEST] <furq> i was going to say i wouldn't trust the ffmpeg cli running for months on end
[18:51:51 CEST] <furq> it doesn't handle dropouts well
[18:51:58 CEST] <Michaela_> I am still confused on the timestamp
[18:52:11 CEST] <Michaela_> did you find a way ?
[18:52:24 CEST] <furq> matroska supports nanosecond timestamps according to the spec
[18:52:27 CEST] <thebombzen> if you only need millisecond precision, then the matroska muxer is good enough
[18:52:49 CEST] <thebombzen> if you want nanosecond precisoin, you might have to modify the libavformat matroska muxer
[18:52:52 CEST] <furq> if you're not using the cli then i assume you can just set the timebase you want with the api and then pass the timestamps through from your capture source
[18:52:53 CEST] <thebombzen> with your own version of ffmpeg
[18:53:10 CEST] <furq> i've never touched the matroska muxer from the api
[18:53:23 CEST] <furq> idk if the 1/1000 restriction is ffmpeg.c or libavformat
[18:53:45 CEST] <thebombzen> most likely libavformat's matroskaenc.c
[18:53:45 CEST] <Michaela_> is there any example of API using mkv, and h.264 ?
[18:54:13 CEST] <furq> https://www.ffmpeg.org/doxygen/trunk/examples.html
[18:54:16 CEST] <furq> those are the only examples i know
[18:54:17 CEST] <furq> of
[18:54:17 CEST] <Michaela_> also , one more questions: when you are encoding with H264, do you still have same number of frames as you would in raw ?
[18:54:25 CEST] <furq> you should
[18:54:35 CEST] <thebombzen> You shouldn't drop any frames unless you tell it to
[18:54:47 CEST] <thebombzen> which if you're linking to libav* directly then just don't explicitly drop a frame
[18:54:49 CEST] <thebombzen> and you'll be good
[18:55:04 CEST] <Michaela_> ok, thanks :)
[18:55:09 CEST] <Michaela_> you guys are the best
[18:55:56 CEST] <thebombzen> I like to think so :)
[18:56:01 CEST] <furq> mostly me though
[18:56:36 CEST] <Michaela_> no seriously helping newbies like me is not easy ;)
[18:57:26 CEST] <thebombzen> but yes. the ffmpeg cli tool (we call it ffmpeg.c sometimes) is a swiss army knife. you don't want to use it for highly-specialized applications
[18:57:40 CEST] <thebombzen> using the api here is the right call
[18:58:11 CEST] <Michaela_> if you could find a nanoseconds or even microseconds options ,let me know
[18:58:34 CEST] <Michaela_> I saw somewhere that you can use SEI
[18:58:49 CEST] <Michaela_> but I don't even know what's SEI
[19:00:10 CEST] <n4zarh> I have following error during building ffmpeg with android ndk: error: libavutil/log2_tab.o: incompatible target (also reverse.o). Removing both .o and .d files with that names did not help. Any idea?
[19:00:10 CEST] <Michaela_> Supplemental Enhancement Information (SEI) message?
[19:01:03 CEST] <n4zarh> this happens only for x86, did not happen for arm
[19:13:12 CEST] <n4zarh> or can anyone just help me create configuration for ffmpeg builds with android ndk? It seems I succeeded only with armeabi, while armeabi-v7a seems to crash and rest (x86, x86_64 and armeabi with neon) just fail to build :( I am clueless about this
[19:13:41 CEST] <BtbN> did you try to build in the same build tree without cleaning it out first or something?
[19:14:48 CEST] <n4zarh> previous build is completely removed when I try to do next one, it just seems that some files in ffmeg directory persists (like reverse.o)
[19:24:37 CEST] <n4zarh> i can show you logs and configure if that's needed, I just have no idea how to build all of those and this is VERY important
[19:46:26 CEST] <thebombzen> n4zarh: "I can show you logs"
[19:46:28 CEST] <thebombzen> well
[19:46:31 CEST] <thebombzen> have you considered just
[19:46:36 CEST] <thebombzen> uploading the logs to some site
[19:46:45 CEST] <thebombzen> and then posting a link? rather than declaring that you could do this
[19:47:13 CEST] <n4zarh> you are right, that was quite stupid
[19:49:09 CEST] <n4zarh> I will build it again (tried to fix error with armeabi-v7a build) and will post everything to pastie or something
[19:50:16 CEST] <BtbN> n4zarh, if some files persist, it's obviously not fully cleaned
[19:50:20 CEST] <BtbN> do a git clean -fxd to be sure
[20:00:21 CEST] <irgendwer4711> hi, is there no tune option for nvenc codec?
[20:02:17 CEST] <n4zarh> huh, clearing all .o and .d files allowed me to build it; i wonder if it will actually work now
[20:18:29 CEST] <BtbN> irgendwer4711, no.
[20:18:56 CEST] <irgendwer4711> BtbN: strange: http://linux.overshoot.tv/wiki/nvidia_nvenc
[20:19:28 CEST] <BtbN> blame them for writing a bad "guide"
[20:19:39 CEST] <BtbN> nvenc also has no -crf
[20:20:13 CEST] <irgendwer4711> ok
[20:22:15 CEST] <Fenrirthviti> It's amusing that command even executes with how wrong they are
[20:23:34 CEST] <BtbN> Fenrirthviti, they shouldn't execute.
[20:24:15 CEST] <Fenrirthviti> That's kinda what I was thinking, but the guide posted results. Who knows?
[20:27:08 CEST] <BtbN> those are private libx264 options, they should throw an error
[20:29:09 CEST] <furq> they're not private
[20:29:16 CEST] <kepstin> BtbN: I think ffmpeg will print a warning if there are options which can't be mapped to a codec avoption, but i don't think it's an error.
[20:29:44 CEST] <rictan> Hello All, I want to know if there is a way to reduce ffmpeg binary (building from source) to anything below 1 megabyte... The primary and only function I want (still stepping through the code) is to allow conversion of h.264 codec to .mp4 wrapper
[20:30:07 CEST] <furq> rictan: --disable-everything and then enable the things you need
[20:30:30 CEST] <rictan> Ive tried doing ./configure parameters such as --enable-small --disable-ffplay/probe/server
[20:31:12 CEST] <rictan> My question is, for my specific function --> h.264 -> .mp4   I am unsure which libaries it uses, or rather, knowing what things i need
[20:31:16 CEST] <BtbN> I'd say sub 1MB is not possible
[20:31:29 CEST] <BtbN> h264 -> mp4 is not a well defined "function".
[20:31:35 CEST] <furq> at a guess you want --disable-everything --enable-protocol=file --enable-decoder=h264 --enable-muxer=mp4
[20:31:39 CEST] <kepstin> rictan: so your source is raw h264, and you want to save it in an mp4 container without re-encoding?
[20:31:39 CEST] <BtbN> do you mean encode with libx264? Do you want to remux other containers to mp4?
[20:31:43 CEST] <rictan> yes
[20:31:44 CEST] <furq> but there might be a couple of other things you need
[20:32:02 CEST] <rictan> im not sure what you mean by without re-encoding
[20:32:06 CEST] <furq> and yeah i'd be surprised if you could get it below 1MB
[20:32:09 CEST] <furq> maybe with strip and upx
[20:32:34 CEST] <kepstin> if you only need one muxer and the h264 parser, it seems maybe possible :/
[20:32:35 CEST] <rictan> with just a bare --enable-small   binary is at 12.7MB
[20:32:44 CEST] <rictan> I see
[20:32:50 CEST] <furq> enable-small just builds with -Os instead of -O2
[20:32:53 CEST] <furq> or 3, or whatever it uses
[20:32:58 CEST] <furq> that's a marginal improvement
[20:33:14 CEST] <rictan> I understand
[20:34:38 CEST] <furq> you'll probably also need to enable some demuxers and parsers
[20:34:43 CEST] <rictan> furq: I will try the parameters you suggested
[20:34:44 CEST] <furq> depending on what your input format actually is
[20:34:54 CEST] <furq> also are you using ffmpeg or are you using the api
[20:35:05 CEST] <furq> if you need an ffmpeg binary then you'll need --enable-programs as well
[20:35:08 CEST] <rictan> ffmpeg
[20:35:17 CEST] <rictan> my goal is to build for arm
[20:35:44 CEST] <rictan> but since im limited in size constraint, I would like to see if I can reduce the size of the binary first in x86 before I begin the process of building for arm
[20:36:11 CEST] <rictan> ok
[20:36:34 CEST] <kepstin> if you just need to mux into mp4, you might also consider using MP4Box or something rather than ffmpeg
[20:36:39 CEST] <kepstin> dunno how big it is
[20:36:39 CEST] <furq> yeah
[20:36:43 CEST] <furq> or l-smash
[20:37:03 CEST] <rictan> thats all i need, mux to mp4
[20:37:10 CEST] <rictan> or rather h.264 to .mp4
[20:37:20 CEST] <rictan> the jargon is still a bit new for me
[20:37:27 CEST] <furq> an amd64 l-smash muxer binary is 550KB
[20:37:32 CEST] <furq> without stripping or compression
[20:37:35 CEST] <rictan> so forgive me if theres any ambiguity in my defined requirements
[20:37:41 CEST] <rictan> wow
[20:37:50 CEST] <rictan> thats exactly what I may need
[20:37:54 CEST] <furq> https://github.com/l-smash/l-smash
[20:38:03 CEST] <furq> it's easy to cross compile as well
[20:38:15 CEST] <rictan> awesome, I will check it out
[20:38:23 CEST] <kepstin> yeah, the ffmpeg cli has enough requirements that the min size I can get it is around 2.5mb or so
[20:38:29 CEST] <furq> but yeah all it does is h264 ES into mp4 and mp4 into mp4
[20:38:33 CEST] <kepstin> (without any tricks
[20:38:35 CEST] <kepstin> )
[20:38:39 CEST] <furq> so if you need to demux any other format it's no good
[20:38:57 CEST] <rictan> nope all is needed is h.264 into mp4
[20:39:01 CEST] <furq> (also other acceptable mp4 codec elementary streams, obviously)
[20:39:25 CEST] <paul_uk> hi, is anyone working with golang here?  I'm using exec.Command to execute ffmpeg.  I'm having problems supplying more than 1 input and it's having trouble with -i and giving me various errors.  Is there a different way of supplying multiple inputs or has anyone got this working with go?
[20:39:31 CEST] <rictan> 2.5mb might be acceptable too kepstin
[20:39:47 CEST] <rictan> you mind sharing what parameters you used?
[20:40:05 CEST] <kepstin> hmm, actually, with --enable-small it's down to about 1.7mb, that's not bad.
[20:40:14 CEST] <furq> is that with disable-everything
[20:40:21 CEST] <rictan> thats good!
[20:40:21 CEST] <kepstin> I'm using `./configure --disable-everything --enable-protocol=file --enable-muxer=mp4 --enable-parser=h264 --enable-demuxer=h264 --enable-ffmpeg --enable-small`
[20:40:36 CEST] <kepstin> which is more or less the minimum to put an elementary h264 stream into an mp4, i think
[20:40:42 CEST] <furq> yeah
[20:40:53 CEST] <rictan> I will try that first
[20:40:54 CEST] <furq> i don't suppose you have an arm compiler there do you
[20:41:06 CEST] <rictan> well thats another problem
[20:41:10 CEST] <furq> i meant kepstin
[20:41:12 CEST] <rictan> im using a linaro toolchain
[20:41:14 CEST] <kepstin> but the ffmpeg cli tool force-enables a bunch of extra demuxers (including mpeg-ts and rtp!?) and filters and stuff :/
[20:41:18 CEST] <furq> rictan: what distro are you on
[20:41:25 CEST] <kepstin> no cross compiler on this box :/
[20:41:26 CEST] <rictan> xubuntu
[20:41:31 CEST] <furq> which version
[20:41:37 CEST] <bencc> I'm creating hls master playlist with several variations and following this example
[20:41:37 CEST] <bencc> https://github.com/gitfu/manifesto/blob/master/variants.py
[20:41:51 CEST] <furq> debian testing has a perfectly good cross toolchain for armhf
[20:42:01 CEST] <bencc> any idea why they use bandwidth that is different than the maxrate?
[20:42:02 CEST] <furq> i'm pretty sure that's made it into ubuntu but i'm not sure which version
[20:42:11 CEST] <bencc> is it just an estimation?
[20:42:33 CEST] <rictan> 16.04
[20:42:57 CEST] <furq> http://packages.ubuntu.com/xenial/crossbuild-essential-armhf
[20:42:59 CEST] <furq> looks like it's there
[20:43:13 CEST] <furq> i use that for cross compiling for rpi, it works great
[20:43:13 CEST] <rictan> great!
[20:43:15 CEST] <rictan> that works
[20:43:51 CEST] <rictan> im assuming for configure parameters --cross-prefix=/path/to/toolchain
[20:44:01 CEST] <rictan> should allow cross compiling for arm I suppose?
[20:44:36 CEST] <furq>  --cross-prefix=arm-linux-gnueabihf- --arch=armv7 --target-os=linux
[20:44:38 CEST] <furq> is what i use
[20:45:09 CEST] <rictan> got it
[20:45:29 CEST] <furq> you'll need to use armel if it's a softfloat cpu
[20:46:08 CEST] <paul_uk> nm figured it out lol
[20:48:57 CEST] <rictan> Thanks so much for your responses all, great help!
[21:02:24 CEST] <rictan> kepstin: after using your parameters and building, I was able to achieve 1.7 MB as well, however, running the ffmpeg to wrap h.264 to .mp4 produces an error
[21:04:34 CEST] <furq> you're better off just using l-smash if that's all you need to do
[21:04:39 CEST] <furq> it has a better license for starters
[21:08:09 CEST] <xeche> Hi. Does anybody have any experience with avcodec_send_frame taking a really long time after seek?
[21:08:35 CEST] <xeche> I've timed the different calls and usually, calls take something on the order of 10 microseconds
[21:08:58 CEST] <xeche> but after a seek, next call to avcodec_send_frames takes 16000~ microseconds
[21:09:23 CEST] <rictan> any readme or documentation for l-smash?
[21:10:07 CEST] <furq> rictan: no but it's pretty self-explanatory
[21:10:31 CEST] <furq> ./configure and the cli tools both have --help sections which explain everything
[21:10:50 CEST] <rictan> sounds good
[21:22:39 CEST] <rictan> furq: worked like a charm... ran ./muxer -i input.264 -o output.mp4
[21:22:58 CEST] <rictan> Thanks for the recommendation, now onto cross compiling for arm
[21:26:29 CEST] <xeche> Sorry. avcodec_send_packet
[21:26:48 CEST] <xeche> Could somebody please point me in the direction of the source file where avcodec_send_packet is implemented?
[21:27:13 CEST] <kepstin> rictan: I can't read your mind to find out what error that command produced, by I bet you just have to add "-c copy" to the command you tried
[21:31:42 CEST] <rictan> kepstin: here is the pastebin... https://pastebin.com/zsfXR3mM
[21:32:32 CEST] <kepstin> huh, weird. I guess it needs a bit more stuff :/
[21:33:09 CEST] <klaxa> xeche: https://www.ffmpeg.org/doxygen/trunk/decode_8c_source.html#l00627
[21:33:58 CEST] <thoraxe> when resampling (changing fps) on video do I also need to use the "aresample" option for the audio? mediainfo is showing me differing frame lengths
[21:34:14 CEST] <xeche> klaxa: thank you
[21:34:14 CEST] <ExeciN> I'm trying to figure out if my videos have constant or variable frame rate. ffprobe reports with "Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuvj420p(pc, smpte170m/bt709/bt709), 1920x1080, 45630 kb/s, 25 fps, 25 tbr, 25k tbn, 50k tbc (default)"
[21:34:34 CEST] <ExeciN> how can I tell if it has a variable or a constant frame rate?
[21:34:36 CEST] <xeche> klaxa: trying to figure out if there's some automatic memory management going on by way of ref counted whatever
[21:35:17 CEST] <klaxa> kinda yes
[21:35:31 CEST] <klaxa> i couldn't figure out how it really works either though
[21:37:51 CEST] <xeche> klaxa: maybe if ffmpeg suddenly decided to allocate a block or clean up something after a seek, that would cause a send packet to take some time, but i've timed all the flushes too, and they take ~0 time
[21:38:47 CEST] <thoraxe> ffmpeg -i ./intro_v07.mov -af aresample=async=1000 -c:v libx264 -r 30 -preset medium -threads 4 30fps-intro.avi
[21:38:56 CEST] <thoraxe> that doesn't seem to "match" the audio/video length either
[21:39:07 CEST] <thoraxe> loading into blender I end up with 200 audio frames and 195 video frames
[21:39:17 CEST] <xeche> Oh well. I give up. I guess seeking real time just isn't going to happen.
[21:39:37 CEST] <xeche> Cheers.
[21:40:38 CEST] <thoraxe> actually it looks like the input file's audio has a "source" and "duration" and source is a bit longer
[21:40:49 CEST] <thoraxe> lemme try a hack
[21:57:37 CEST] <thebombzen> ExeciN: in your case it does
[21:58:30 CEST] <thebombzen> the "tbr" is the smallest "framerate" needed to reconstruct the video. as in the "tbr" or "timebase rate" is enough. so here, 25 tbr means all the frames are on multiples of 1/25 of a second
[21:58:51 CEST] <thebombzen> but having it be 25 fps means that it's actually 25 cfr
[21:59:31 CEST] <thebombzen> I'm not sure how universal this is, but in general ffmpeg will report the FPS for cfr content and only report the TBR for non-cfr content
[22:03:19 CEST] <thebombzen> however, keep in mind that the avg_frame_rate reported is sometimes just false
[22:03:27 CEST] <thebombzen> I have a video that's got 500 fps reported as its framerate
[22:08:54 CEST] <ChocolateArmpits> ExeciN, Checking timestamps probably
[22:13:22 CEST] <thebombzen> unfortunately, there isn't a toally easy way to tell. some containers have a cfr flag, but it's sometimes unreliable
[22:13:37 CEST] <thebombzen> because the cfr reported can be unequal to the actual cfr
[22:30:20 CEST] <holgersson> Hi everyone! Im running wit3.3
[22:30:54 CEST] <holgersson> *with version 3.3 of ffmpeg and have some issues finding good parameters for x264 re-encoding.
[22:31:44 CEST] <ChocolateArmpits> holgersson, are you trying to hit original quality ?
[22:31:54 CEST] <ChocolateArmpits> Or fit under some constraints?
[22:32:17 CEST] <holgersson> ChocolateArmpits: Yes, I want to reencode FullHD material with awfully big file size in mkv in a container.
[22:32:29 CEST] <holgersson> *in mkv as a container
[22:34:10 CEST] <holgersson> Well, I was going to ask if some would like to share a good config line for that :)
[22:35:21 CEST] <ChocolateArmpits> Well if it's just basic like that then ffmpeg -i input -vcodec libx264 -crf 12 -acodec aac -b:a 384k output.mkv
[22:36:03 CEST] <ChocolateArmpits> if the performance isn't satisfactory you can set -preset parameter to faster/veryfast/superfast
[22:37:24 CEST] <klaxa> crf 12 is might low, good quality, rather big filesize
[22:37:42 CEST] <klaxa> i suggest trying out a few different crf values and only encoding a small portion of your video for review first
[22:38:19 CEST] <holgersson> I already cut out a 2min part video-only for testing
[22:39:03 CEST] <klaxa> good!
[22:39:52 CEST] <klaxa> what is your reason for re-encoding?
[22:40:04 CEST] <klaxa> save space? compatibility? something else?
[22:40:18 CEST] <holgersson> klaxa: The video files are quite big, so saving space.
[22:40:57 CEST] <klaxa> i would suggest -preset veryslow then, it does more exhaustive searches for ways to compress, but takes longer
[22:41:07 CEST] <holgersson> klaxa: ~160MB per minute for video only ^^
[22:41:28 CEST] <klaxa> and try out a few crf values, 12 is quite low but should be almost visually transparent
[22:41:56 CEST] <holgersson> Thanks, Ill try these out!
[22:41:59 CEST] <klaxa> if it looks good enough try to increase it until it is no longer acceptable and use the last "good" value
[22:42:26 CEST] <holgersson> OK
[22:42:28 CEST] <klaxa> keep in mind that is a really subjective measurement though
[22:42:42 CEST] <holgersson> ofc
[22:42:51 CEST] <klaxa> since quality is pretty subjective in the first place :P
[22:43:38 CEST] <holgersson> its IMHO quite good in the original files ;)
[22:44:56 CEST] <holgersson> BTW another topic: Is it possible to "stretch" old DVD images to FullHD size, maybe with black bars to compensate the different image format (4:3 vs 16:9) and still get something watchable? If, is there some specific name for this I can look up?
[22:46:32 CEST] <holgersson> hrhr, -crf 12 actually increased the file size
[22:47:36 CEST] <ChocolateArmpits> holgersson, is the HD resolution for the DVD necessary? You aren't going to get any better picture out of this
[22:49:02 CEST] <holgersson> ChocolateArmpits: I thought so, but I remember I read something *years* ago about stretching without losing quality, but I dont know how serious this was though.
[22:56:15 CEST] <klaxa> holgersson: one could change the display aspect ratio, but that would not add letterboxes, adding letterboxes requires re-encoding
[22:56:32 CEST] <klaxa> also letterboxing is... well at least frowned upon by me and probably many other people
[22:56:53 CEST] <klaxa> >opinions :P
[22:57:07 CEST] <holgersson> OK, thanks - Ill let that stuff be and focus on re-encoding the awfully big stuff.
[23:28:38 CEST] <kepstin> holgersson: sure you can upscale and re-encode in HD, but the result will only be marginally better than simply making the window bigger when playing back, and the encoded video will be bigger.
[23:29:13 CEST] <kepstin> (there's some slow upscaling filters you can use which give slightly better results than the realtime ones used during playback, depending on video content)
[23:30:37 CEST] <holgersson> Maybe Ill try it later
[00:00:00 CEST] --- Tue Apr 25 2017