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

[burek]

[00:04:11 CEST] <kms_> i change it by mkvmerge --default-duration 0:60fps  in.webm -o out.webm
[01:51:24 CEST] <Tatsh> anyone ever blurred faces using only ffmpeg?
[01:51:39 CEST] <Tatsh> only for a short portion of the video, they are relatively static
[02:09:38 CEST] <thebombzen> is there a way to unset a certain metadata key but otherwise copy the rest?
[02:10:00 CEST] <Tatsh> if it's an mp4 you could consider using atomicparsley
[02:10:29 CEST] <thebombzen> it's a matroska that I think was originally muxed with libmkv+libebml
[02:10:37 CEST] <thebombzen> there's a metadata key that's set: NUMBER_OF_BYTES
[02:10:55 CEST] <Tatsh> there's a way to copy the entire metadata, and maybe an argument after that would overwrite
[02:11:06 CEST] <Tatsh> and you could set that to blank if that's acceptable
[02:11:16 CEST] <thebombzen> this of course is pretty useless if you re-encode but ffmpeg copies it anyway. however I don't want to strip all the metadata
[02:11:31 CEST] <thebombzen> the question is how to delete the metadata key
[02:13:17 CEST] <Tatsh> well you don't have to re-encode
[02:13:23 CEST] <Tatsh> you can always use -codec copy
[02:13:53 CEST] <Tatsh> ffmpeg -i somefile.mkv -codec copy -map_metadata 0
[02:14:05 CEST] <Tatsh> with -map_metadata is where you might be able to filter some metadata out?
[02:16:56 CEST] <thebombzen> I don't think you understand my question
[02:17:23 CEST] <Tatsh> ffmpeg does not modify the input files whatsoever
[02:17:28 CEST] <Tatsh> it can only make a copy
[02:18:30 CEST] <thebombzen> again, I don't think you understand my question
[02:18:54 CEST] <thebombzen> the good news is I figured it out
[02:19:25 CEST] <thebombzen> if you use "-metadata:s KEY=" then ffmpeg is smart enough to delete the metadata key rather than set it to the empty string or complain about an error
[02:19:34 CEST] <thebombzen> I'm not sure if this is the canonically recommended method but it works
[02:20:22 CEST] <thebombzen> Tatsh: to answer your question, it is definitely possible but to do it efficiently or easily? I'd recommend a nonlinear editor
[02:21:30 CEST] <thebombzen> the only way I can think to do that with ffmpeg is figure out a bunch of coordinates by hand and then split the stream, crop the copy, pad it, run it through a blur filter, and then overlay it back
[02:21:35 CEST] <thebombzen> this is horribly inefficient
[02:23:27 CEST] <Tatsh> well, it's about the same amount of time spent in a non-linear editor
[02:24:02 CEST] <Tatsh> would be cool if a built-in face detection+blur thing was there, because i don't need to blur out just some faces, but all faces
[02:37:49 CEST] <factor> i was trying to figure out how to switch between two overlay images on demand to give me a double buffer to manipulate.
[02:38:59 CEST] <factor> Can I change the -i png on demand? Does ffmpeg pull the image again if it has changed?
[02:53:39 CEST] <factor> Was looking at zmq , could that do whati wanted like change overlay image on demand.
[03:01:18 CEST] <DHE> factor: at least on unix you can atomically replace a file without hassle
[03:02:19 CEST] <factor> DHE: So I can change my overlay image in place.
[03:05:10 CEST] <DHE> under unix write the new file in its entirety to some other file in the same file system (typically the same directory) and `mv` it over the old/active video.
[03:05:27 CEST] <DHE> or in programming languages use the rename() function
[03:10:04 CEST] <factor> DHE: I just tried that and it did not work.
[03:10:48 CEST] <factor> I root at streamcaster:/opt# cp flame2.png dummy.png root at streamcaster:/opt# cp flame1.png dummy.png
[03:11:04 CEST] <factor> using dummy.png as the overlay
[03:11:27 CEST] <factor> it kept the same flame1.png image in the stream.
[03:12:33 CEST] <factor> DHE: I used this for the overlay mixing. -vf "movie=dummy.png [watermark]; [in][watermark] overlay=10:10 [out]"
[03:55:03 CEST] <Tatsh> i got footage of my car going through a car wash and at 4x it's almost like seizure inducing
[03:55:07 CEST] <Tatsh> :)
[05:51:15 CEST] <Ekho> Hmm, seems when the ffmetadata muxer only uses the first 1023 bytes of each tag (counting the tagname and '=' sign) when reading from file. EX: ARTIST=really_long_name_over_1016_bytes would have nothing after the 1016th byte of the name in the tag. Adding the same tag from with -metadata TAG=VALUE works fine, though after ~100KiB you typically run into the argument length limit.
[05:52:27 CEST] <Ekho> Not sure how to get around this
[05:54:58 CEST] <Ekho> s/seems when/seems/
[07:58:52 CEST] <factor> Where are sets of good examples for using zmqsend.
[08:53:01 CEST] <thomedy> hey im trying to transcode mp4 or webm to raw
[10:51:38 CEST] <hendry> by default iiuc ffmpeg re-encodes to the best bitrate for the input?
[10:52:02 CEST] <kerio> re-encodes what?
[10:52:03 CEST] <kerio> into what?
[10:52:05 CEST] <hendry> with a command like https://github.com/kaihendry/recordmydesktop2.0/blob/master/htmlvideo#L36
[10:52:44 CEST] <kerio> no, that will just use the default libx264 settings
[10:52:46 CEST] <hendry> so i encode my camera's high bitrate mp4 with -movflags +faststart -pix_fmt yuv420p -c:v libx264 ... the output is about a ~4Mbps bitrate file by default
[10:52:58 CEST] <kerio> whether or not they're the correct for you is up to you
[10:53:09 CEST] <hendry> the default seems pretty darn good
[10:53:40 CEST] <hendry> is it correct to say it's a re-encoding to a more appropriate bit rate? (trying to describe what it does by default)
[10:54:22 CEST] <hendry> or maybe a better question is, what is the "default libx264 settings" RE bit rate ?
[10:54:25 CEST] <kerio> if the default is a VBR trying to target a specific crf, then sure
[10:54:34 CEST] <kerio> idk i'm trying to figure it out
[10:55:11 CEST] <furq> the default is crf 23
[10:55:16 CEST] <kerio> D:
[10:55:21 CEST] <kerio> so ugly D:
[10:55:22 CEST] <furq> which is "ok"
[10:55:42 CEST] <kerio> -crf 18 or gtfo
[10:55:52 CEST] <furq> i'd use 19-21 for archival, but 23 will be broadly fine
[10:56:04 CEST] <furq> 23 at preset medium, i should say
[10:56:18 CEST] <furq> since the preset affects the meaning of the crf
[10:56:22 CEST] <kerio> oh ;o
[10:56:39 CEST] <kerio> wait why would the preset affect the meaning of crf
[10:56:47 CEST] <furq> why wouldn't it
[10:56:53 CEST] <kerio> isn't crf a check on the resulting image
[10:57:16 CEST] <kerio> i'd expect a lower preset to result in a bigger video, not a worse-looking one
[10:57:31 CEST] <furq> that is intuitively how it would work
[10:57:33 CEST] <furq> but it isn't how it works
[10:57:36 CEST] <kerio> :(
[10:57:43 CEST] <kerio> why does everything suck
[10:58:07 CEST] <furq> i'm pretty sure crf just does a motion analysis to determine what q to use
[10:58:12 CEST] <furq> i'm no expert though
[10:58:33 CEST] <kerio> hendry: anyway the answer is "yes"
[10:58:43 CEST] <furq> more motion = higher q
[10:58:58 CEST] <hendry> furq: what is your full archival line again? do you h264 or have you tried others like libx265 ?
[10:59:15 CEST] <furq> so you don't end up compressing that hbo logo at q 18 and using 100MB for the first 10 seconds
[10:59:36 CEST] <kerio> btw is there a reason to not use +faststart all the time?
[10:59:40 CEST] <furq> hendry: normally -crf 20 -preset veryslow -tune film
[10:59:47 CEST] <kerio> other than the obvious "don't use mp4" :^)
[10:59:54 CEST] <furq> obviously -tune depends a lot on the content
[11:00:05 CEST] <furq> kerio: not really but it matters less these days
[11:00:33 CEST] <hendry> kerio: +faststart is required to move the MOOV bit to the front so Web players can play it back quickly
[11:00:42 CEST] <furq> if i'm parallel batch remuxing to mp4 then i'll disable faststart because it's slow as shit
[11:00:45 CEST] <kerio> yes, i'm aware of what +faststart does
[11:00:50 CEST] <kerio> furq: oh ;o
[11:00:54 CEST] <furq> and then do it sequentially with l-smash
[11:01:21 CEST] <furq> or i'll just do the whole thing with l-smash
[11:01:28 CEST] <hendry> kerio: sorry, so yes, it should always be done imo :}
[11:01:41 CEST] <furq> web players can play it back quickly regardless these days
[11:01:52 CEST] <furq> as long as your server supports range requests
[11:01:59 CEST] <hendry> i was looking at AWS Elastic Transcoder profiles, and bizaarely, they seem limit resolution and bit rate, e.g. https://s.natalian.org/2017-06-11/aws-web-profile.png
[11:02:14 CEST] <hendry> Which I don't like, so now I have come up with my own ffmpeg pipeline. Doh.
[11:02:31 CEST] <furq> that's not that bizarre if they charge by media minute
[11:02:38 CEST] <furq> which i assume they do
[11:02:51 CEST] <furq> obviously 4k60 is going to take much longer to encode at the same settings
[11:03:28 CEST] <kerio> furq: what about streaming tho
[11:03:39 CEST] <furq> what about it
[11:03:39 CEST] <kerio> although i guess fragmented isobmff is a whole different bag of dicks
[11:03:48 CEST] <hendry> furq: well option should be there, since that might be what someone wants with a certain input
[11:03:48 CEST] <furq> fmp4 isn't faststart
[11:03:51 CEST] <furq> that's a whole different thing
[11:03:59 CEST] <kerio> still .mp4 tho :^)
[11:04:06 CEST] <furq> hendry: i guess they haven't implemented the pricing tier for it yet
[11:04:35 CEST] <hendry> furq: what i don't understand is the need to segment videos for Web playback. Why isn't +faststart & httpd with range support work (i think S3+CF support range requests)
[11:04:50 CEST] <furq> it does work
[11:04:55 CEST] <furq> and you only need one or the other
[11:05:27 CEST] <hendry> furq: i'd rather have one file that worry about a bunch of files
[11:05:35 CEST] <furq> well good because that works
[11:05:44 CEST] <furq> you only need to fragment for live streaming
[11:06:03 CEST] <hendry> how come no vendor streaming company seems to do that?
[11:06:10 CEST] <furq> and that's only because the wonderful world of web browsers has left us with no alternative for livestreaming than hls and dash
[11:06:25 CEST] <kerio> good old https/ip
[11:06:28 CEST] <furq> both of which suck massively compared to actual protocols that aren't just a bunch of http requests
[11:06:42 CEST] <furq> but also don't require google and apple to agree on anything
[11:06:49 CEST] <kerio> well, http2 is pretty efficient
[11:06:50 CEST] <furq> and also firewalls i guess but who cares
[11:07:19 CEST] <hendry> maybe there is no DRM solution for a one mp4 approach? Just speculating
[11:07:30 CEST] <furq> i have no idea when it comes to drm
[11:07:33 CEST] <kerio> hendry: the future of HLS is single fmp4 file with playlist
[11:07:47 CEST] <furq> i suspect drm is only supported through dash or rtmp
[11:07:55 CEST] <furq> and dash usually uses fragments
[11:08:37 CEST] <furq> if you're just doing unencrypted vod then all you need is an mp4 with the right codecs
[11:08:57 CEST] <furq> it doesn't even really need to be faststart
[11:09:01 CEST] <furq> although it's still better if it is
[11:09:06 CEST] <hendry> never knew about "fmp4 files" looks like +faststart 2.0. Does ffmpeg support it?
[11:09:16 CEST] <furq> yeah although i forget the flags to mux it
[11:09:23 CEST] <hendry> and importantly do major browsers support fmp4?
[11:09:28 CEST] <furq> yeah
[11:09:45 CEST] <furq> any browser that supports mpeg-dash has to support fmp4
[11:11:01 CEST] <hendry> googling how to generate a fmp4 with ffmpeg and i got https://stackoverflow.com/questions/38227301/transcoding-fmp4-to-hls-while-writing-on-ios-using-ffmpeg (an un-answered question)
[11:12:02 CEST] <kerio> can you just keep reading the same fragmented mp4 to play it
[11:12:05 CEST] <kerio> or do you still have to refresh the .m3u8
[11:12:12 CEST] <furq> -movflags frag_keyframe+empty_moov
[11:12:16 CEST] <furq> apparently
[11:12:53 CEST] <furq> you presumably want to use that with the segment muxer
[11:13:22 CEST] <thebombzen> not even sure why we care so much about making it so DRM is possible
[11:13:28 CEST] <kerio> furq: nou D:
[11:13:30 CEST] <kerio> single-file
[11:13:39 CEST] <kerio> unless the segment muxer can also make the m3u8 with byteranges
[11:13:49 CEST] <furq> shrug
[11:14:44 CEST] <thebombzen> streaming DRM has the effect of making it slightly more difficult to grab a stream, and making it a pain in the ass for linux users
[11:14:49 CEST] <thebombzen> and not much else
[11:15:08 CEST] <furq> i also have opinions that everyone else in the room shares
[11:15:23 CEST] <hendry> furq: where did you find that? is there no +faststart additionally there ?
[11:15:32 CEST] <furq> no
[11:15:47 CEST] <furq> there's no moov atom to move
[11:16:02 CEST] <furq> that's a sentence i'm glad i was able to type instead of say
[11:17:32 CEST] <hendry> furq: i thought there was a moov atom at the end of a camera produced mp4 in any case
[11:17:43 CEST] <furq> well yeah but you're remuxing it
[11:17:44 CEST] <hendry> and +faststart simply moves that to the beginning of the file??
[11:18:16 CEST] <furq> you're remuxing it to a format that doesn't have moov atoms
[11:18:18 CEST] <kerio> "simply"
[11:18:19 CEST] <furq> hence empty_moov
[11:18:41 CEST] <furq> it's also not that simple, ffmpeg is dumb so it has to remux it, then write a new moov atom, then rewrite the entire file again with the moov atom at the start
[11:18:56 CEST] <furq> which is why it's so much slower than using a dedicated mp4 remuxer which just moves the existing moov atom
[11:19:35 CEST] <furq> it's also why you should never run multiple faststart remuxes in parallel on a hard disk
[11:19:47 CEST] <furq> unless you really want an inoperable computer
[11:19:55 CEST] <hendry>  
[11:20:08 CEST] <kerio> pleb without a SSD :^)
[11:21:11 CEST] <furq> they don't make ssds big enough to fit all my radiohead bootlegs
[11:21:31 CEST] <kerio> pls no meanie
[11:21:55 CEST] <hendry> furq: good info
[11:24:03 CEST] <hendry> but why not use h265 for archival ? surely it's better that h264? :}
[11:24:18 CEST] <kerio> can't you just leave enough space for the moov atom at the beginning
[11:24:20 CEST] <kerio> and then seek back
[11:24:55 CEST] <furq> a ferrari f40 is better than a honda civic, but i wouldn't drive to the shops in one
[11:25:18 CEST] <furq> it's probably best if you don't analyse that analogy too much
[11:32:24 CEST] <hendry> furq: hokay... just trying to come up with some switches to archive wedding and other footage i take
[11:32:50 CEST] <kerio> oh so it's very long-term stuff?
[11:32:51 CEST] <hendry> furq: i think i'll adopt your settings and try out -movflags frag_keyframe+empty_moov
[11:33:06 CEST] <kerio> wait waht
[11:33:07 CEST] <hendry> kerio: guess so, guess i won't touch it in a blue moon
[11:33:20 CEST] <kerio> fragmented isobmff is for streaming
[11:33:22 CEST] <kerio> not archival
[11:33:40 CEST] <hendry> i want it to be Web playback-able, I am planning to keep stuff on S3
[11:33:55 CEST] <hendry> don't want to download the file to quickly see what's there
[11:36:59 CEST] <furq> then use faststart
[11:37:22 CEST] <furq> if you're just remuxing then don't use ffmpeg at all
[11:38:44 CEST] <kerio> if you're just remuxing use ffmpeg
[11:38:46 CEST] <kerio> and put your stuff into mkv
[11:38:56 CEST] <kerio> praise the matroska
[11:39:39 CEST] <furq> well you won't be able to view it in a browser then
[11:40:03 CEST] <furq> also if it's off a camera then i assume it's 30000/1001 fps, which matroska doesn't understand
[11:40:19 CEST] <kerio> wait, really?
[11:40:24 CEST] <furq> yes
[11:40:25 CEST] <kerio> how did they fuck it up so bad
[11:40:30 CEST] <furq> matroska always uses a timebase of 1/10000
[11:40:36 CEST] <furq> or at least it does with ffmpeg
[11:40:36 CEST] <kerio> it's like one of the three most used framerates
[11:41:00 CEST] <furq> it's always 1/(10^n) iirc
[11:41:09 CEST] <furq> but ffmpeg always uses 10000
[11:41:45 CEST] <furq> that still wouldn't let you accurately store 30000/1001 though
[11:43:35 CEST] <hendry> furq: remuxing? that means doing the MOOV bit move right?
[11:43:46 CEST] <furq> moving the streams into a new container
[11:44:05 CEST] <hendry> furq: i want to make sure the MP4 file from the camera is re-encoded to some sane bitrate and not take too much space
[11:44:07 CEST] <furq> if you're actually reencoding then use ffmpeg
[11:44:15 CEST] <hendry> furq: and make it playable for the Web
[11:45:00 CEST] <furq> just use ffmpeg with faststart then
[11:45:10 CEST] <furq> fmp4 is only useful for livestreaming
[11:47:58 CEST] <thebombzen> furq: ffmpeg always uses 1000
[11:48:19 CEST] <thebombzen> afaik matroska stores 24000/1001 as 2997/125
[11:54:57 CEST] <kerio> still wrong tho
[11:55:38 CEST] <kerio> 1001 is 7*11*13, 125 is a power of 5
[12:25:50 CEST] Action: hendry 's power tripped
[12:26:55 CEST] <factor> Has anyone used zmq for swapping different watermarks in realtime?
[17:19:24 CEST] <bencc> I have 500MB mp4 file that requires loading 35MB in the browser before starting to play
[17:19:38 CEST] <bencc> how can I verify that it has the index in the beginning of the file?
[17:19:47 CEST] <BtbN> run qt-faststart on it.
[17:20:00 CEST] <BtbN> afterwards, it will
[17:20:28 CEST] <furq> you can check with l-smash
[17:20:43 CEST] <furq> i've got a sh function somewhere that does it
[17:22:31 CEST] <furq> http://vpaste.net/C5Pdg
[17:22:45 CEST] <bencc> I'm already using 'movfalgs +faststart':
[17:22:48 CEST] <bencc> ffmpeg -nostats -loglevel error -i video.mkv -c:v copy -c:a copy -movflags +faststart -threads 1 video.mp4
[17:22:58 CEST] <furq> well then it does
[17:23:00 CEST] <bencc> that's why I want to verify
[17:23:18 CEST] <BtbN> just look at the output, it even writes a line about moving it at the end
[17:23:35 CEST] <furq> if you really want to doublecheck then boxdumper will do it
[17:23:42 CEST] <furq> or maybe atomicparsley or whatever it's called
[17:23:48 CEST] <furq> if moov appears before mvhd then it's faststart
[17:23:56 CEST] <bencc> furq: looking for boxdumper
[17:24:05 CEST] <furq> https://github.com/l-smash/l-smash
[17:24:06 CEST] <bencc> what about keyframes? can it make a difference?
[17:24:26 CEST] <furq> well yeah if it's downloading 35MB before it plays then it's probably some property of the video stream
[17:24:33 CEST] <furq> not sure what that would be though
[17:24:50 CEST] <furq> if it wasn't faststart and your httpd doesn't support range requests then it'd have to download the entire thing
[17:25:27 CEST] <bencc> this is the part that encodes the video:
[17:25:28 CEST] <bencc> -vcodec libx264 -pix_fmt yuv420p -preset:v veryfast -crf 23
[17:25:39 CEST] <furq> shrug
[17:25:44 CEST] <furq> maybe it's just your browser's video player filling the cache
[17:25:45 CEST] <bencc> should I add a flag to add more keyframes?
[17:25:45 CEST] <BtbN> -c:v
[17:26:17 CEST] <bencc> BtbN: -c:v instead of -vcodec?
[17:26:27 CEST] <furq> that won't make a difference but -vcodec is deprecated
[17:26:30 CEST] <BtbN> yes, vcodec is kinda deprecated
[17:26:32 CEST] <bencc> ok
[17:26:42 CEST] <furq> it's redundant anyway, x264 is the default for mp4
[17:27:10 CEST] <bencc> should I specify keyframe interval?
[17:27:18 CEST] <furq> i don't think that'll make a difference
[17:27:24 CEST] <BtbN> that won't have any effect on startup time
[17:27:28 CEST] <furq> if i had to guess i'd say it was your browser's caching
[17:27:32 CEST] <BtbN> it always starts with one for obvious reasons
[17:27:44 CEST] <furq> yeah
[17:30:36 CEST] <bencc> I think I have the wrong c:a and c:v order:
[17:30:37 CEST] <bencc> ffmpeg -nostats -loglevel error -i video.mkv -c:v copy -c:a copy -movflags +faststart -threads 1 video.mp4
[17:30:40 CEST] <bencc> instead of:
[17:30:47 CEST] <bencc> ffmpeg -nostats -loglevel error -i video.mkv -c:a copy -c:v copy -movflags +faststart -threads 1 video.mp4
[17:30:54 CEST] <bencc> checking in the command line
[17:31:08 CEST] <furq> that makes no difference at all
[17:31:12 CEST] <furq> also you can use -c copy
[17:31:43 CEST] <bencc> ok
[17:34:07 CEST] <furq> some pedant will point this out if i don't amend it, so here it is, even though it's of no consequence
[17:34:12 CEST] <furq> http://vpaste.net/xD1Qb
[17:34:18 CEST] <furq> thank you for your understanding
[17:45:04 CEST] <bencc> this is the structure of the file:
[17:45:05 CEST] <bencc> https://pastebin.com/raw/kBq91y6C
[17:45:28 CEST] <bencc> moov is between  32061684 and 32061716
[17:45:43 CEST] <bencc> what do I have between ftyp and moov?
[17:46:42 CEST] <bencc> why is moov so large?
[17:55:24 CEST] <ChocolateArmpits> bencc, your file is long that's why
[17:55:35 CEST] <ChocolateArmpits> 4 hour video is about 9-10 megabytes
[17:55:42 CEST] <ChocolateArmpits> yours is only 3 megs
[17:55:58 CEST] <ChocolateArmpits> you can lower it by using -chunk_duration 1000k
[17:58:39 CEST] <bencc> 1000k microseconds?
[17:58:52 CEST] <bencc> meaning a chunk_duration of 1 second?
[17:58:58 CEST] <ChocolateArmpits> yes
[17:59:04 CEST] <bencc> what's the default?
[17:59:08 CEST] <ChocolateArmpits> the default is something low so it produces more chunks
[17:59:28 CEST] <bencc> will large chunk hurt seeking?
[17:59:28 CEST] <ChocolateArmpits> idk exactly, maybe 0.1s
[17:59:35 CEST] <ChocolateArmpits> at 1 second not at all
[17:59:42 CEST] <bencc> thanks
[17:59:44 CEST] <bencc> I'll try it
[17:59:53 CEST] <bencc> I'll also decrease the video file
[17:59:59 CEST] <ChocolateArmpits> I had not problems and encoded countless hours of material using that
[18:00:08 CEST] <bencc> it seems that this specific recording should be 80 minutes instead of 400 mintues
[18:00:28 CEST] <bencc> where do I put "-chunk_duration 1000k" ?
[18:00:30 CEST] <furq> ChocolateArmpits: that's 32MB
[18:00:41 CEST] <bencc> this is my command:
[18:00:42 CEST] <bencc> ffmpeg -nostats -loglevel error -i video.mkv -c:a copy -c:v copy -movflags +faststart -threads 1 video.mp4
[18:00:44 CEST] <ChocolateArmpits> furq, what's 32mb?
[18:00:52 CEST] <furq> 16:55:42 ( ChocolateArmpits) yours is only 3 megs
[18:01:05 CEST] <ChocolateArmpits> aww snap
[18:01:11 CEST] <furq> that'd explain it anyway
[18:01:52 CEST] <ChocolateArmpits> yeah I've never gotten sizes that large
[18:01:53 CEST] <ChocolateArmpits> ever
[18:02:32 CEST] <ChocolateArmpits> Maybe it balloons due to storing file address too ?
[18:02:49 CEST] <ChocolateArmpits> so the bigger the file the lengthier a chunk reference will be ?
[18:03:33 CEST] <furq> i would assume so
[18:03:52 CEST] <furq> i was going to recommend remuxing with l-smash but i just checked something i remuxed and the moov is 3MB for 45 minutes
[18:04:33 CEST] <furq> i know mp4box lets you set the chunk duration but idk if l-smash does
[18:05:33 CEST] <furq> also, fuck anything that outputs help text on stderr
[18:07:07 CEST] <furq> aha
[18:07:16 CEST] <furq> remuxer --max-chunk-duration=1000 -i foo.mp4 -o bar.mp4
[18:16:47 CEST] <bencc> ChocolateArmpits:  where do I put "-chunk_duration 1000k" ?
[18:17:13 CEST] <DHE> parameters applying to the input file are specified before the input filename, parameters applying to the output file are specified before the output filename
[18:18:11 CEST] <bencc> like this?
[18:18:13 CEST] <bencc> ffmpeg -nostats -loglevel error -i video.mkv -c:a copy -c:v copy -chunk_duration 1000k -movflags +faststart -threads 1 video.mp4
[18:20:20 CEST] <furq> that should just be 1000
[18:20:26 CEST] <furq> chunk_duration is in ms
[18:21:05 CEST] <bencc> ok
[18:21:25 CEST] <bencc> chunk_duration is only for the moov atom? doesn't requre re-encoding?
[18:21:50 CEST] <furq> no
[18:22:13 CEST] <bencc> no?
[18:22:57 CEST] <bencc> no is a confusing answer :) you can understand it as either way
[18:23:38 CEST] <DHE> never ask a question containing a negative then. english is stupid that way
[18:24:25 CEST] <bencc> this give me the same moov atom size:
[18:24:34 CEST] <bencc> ffmpeg -nostats -loglevel error -i video.mkv -c:a copy -c:v copy -chunk_duration 1000 -movflags +faststart -threads 1 out.mp4
[18:25:24 CEST] <bencc> do I need to re-encode?
[18:27:01 CEST] <bencc> furq: chunk_duration is in microseconds. I need 1000k after all
[18:27:12 CEST] <furq> oh
[18:27:14 CEST] <furq> that's stupid
[18:27:35 CEST] <bencc> that's clever
[18:27:40 CEST] <bencc> it make you think :)
[18:27:46 CEST] <bencc> be better at math
[18:29:58 CEST] <bencc> what does a 'chunk' means?
[18:30:15 CEST] <bencc> is it the time between keyframes?
[19:26:44 CEST] <holla> hi there, i have a .ts file containing 3 streams: 0.1 vid h264 / 0.2 audio acc / 0.3 'data' ?? what's data?
[19:27:43 CEST] <DHE> could be a number of things. sometimes it's key data used for encrypted transmissions. you see that on some satellite receivers' output
[19:28:03 CEST] <DHE> in all likelyhood it's not important as long as the video/audio play correctly
[19:29:12 CEST] <furq> data is usually a private stream
[19:29:24 CEST] <furq> which could be anything, but is often what DHE said
[19:30:54 CEST] <holla> is there a way to track it down?
[19:31:33 CEST] <DHE> wireshark might be able to help you if you really really care. dump the raw PMT data
[19:31:46 CEST] <DHE> (wireshark filter "mpeg_pmt" I believe)
[19:32:04 CEST] <DHE> I still vote for "ignore it" though
[19:32:07 CEST] <holla> i already dumped the stream to hdd
[19:32:21 CEST] <holla> thought there might be something interesting in it
[19:32:38 CEST] <holla> but it doesn't seem to be a subtitle, as far as i can say
[19:33:00 CEST] <DHE> load wireshark. File, Open, and select this .ts file
[19:33:02 CEST] <furq> subtitle streams should be detected properly
[19:33:37 CEST] <furq> unless this is atsc in which case they're muxed into the video stream in some fucked up way
[19:33:52 CEST] <furq> either way it wouldn't be in a private stream
[19:34:01 CEST] <holla> can i dump just that stream? ffmpeg -i foo.ts -map 0:3 out_stream3.suf
[19:34:06 CEST] <DHE> a53 closed captions for teh win!
[19:34:18 CEST] <furq> yeah i'm glad dvb doesn't do that
[19:34:29 CEST] <DHE> holla: are you gonna run wireshark or not?
[19:34:32 CEST] <furq> and also that i'm not deaf so i don't care about subtitles anyway
[19:34:56 CEST] <DHE> furq: they're nice when you're in an office and have to keep the TV muted
[19:35:05 CEST] <holla> actually i don't have it installed on that box iirc - but i could do
[19:35:08 CEST] <furq> i guess
[19:36:48 CEST] <QH> Hi. Does anyone know where I can get hold of the ffmpeg-20160712-df1dc52-win32-static release of ffmpeg? I know it's now unsupported, but the binaries are useful to me.
[19:37:06 CEST] <furq> windows xp is it
[19:37:18 CEST] <QH> Vista
[19:37:31 CEST] <DHE> oh god I'm sor sorry
[19:37:37 CEST] <furq> doesn't look like it's in https://ffmpeg.zeranoe.com/builds/win32/static/
[19:37:56 CEST] <furq> fyi the reason newer builds don't work is because of libmfx
[19:38:06 CEST] <furq> if you build it yourself without libmfx then it'll work on <7
[19:38:45 CEST] <QH> Zeranoe tweeted in December "ffmpeg-20160712-df1dc52-win32-static used to be downloaded a lot before it was removed, and I'd like to know what was downloading it." It is apparently the last version supported in XP and Vista.
[19:39:27 CEST] <QH> Is there a version already compiled without libmfx? I've never compiled anything before so wouldn't know where to start.
[19:39:48 CEST] <c_14> If I remember correctly "a lot" was many many terabytes of bandwidth
[19:40:14 CEST] <QH> Ah, so it was a spike?
[19:40:37 CEST] <c_14> probably some scripts downloading the release every time for something instead of downloading it once and then keeping a local copy
[19:45:25 CEST] <ChocolateArmpits> QH, what about getting a slightly older release?
[19:46:12 CEST] <furq> zeranoe isn't hosting any which predate libmfx
[19:46:26 CEST] <QH> I have an older release that came with a previous version the software I'm trying to use it with, but I wouldn't mind having the latest version that would work.
[19:47:16 CEST] <QH> (mainly because the software has been updated to use a version I can't use on Vista)
[19:56:17 CEST] <QH> Out of interest, if libmfx causes ffmpeg to not work on XP, Vista and other older Windows versions, why not create a fork to the main project to compile without it? Or use another library? Or is the library so vital that it shouldn't be compiled without it in case it breaks more?
[19:58:58 CEST] <furq> the zeranoe builds aren't official
[19:59:40 CEST] <BtbN> Why make an effort to support a dead OS?
[20:01:45 CEST] <ChocolateArmpits> Not for support, so older machines could also enjoy ffmpeg
[20:02:38 CEST] <QH> According to a number of news sites, versions of Windows prior to 7 seem to still be popular - especially when a particular piece of malware hit the news headlines more recently. But it seems a simple suggestion of "build it yourself without libmfx then it'll work on <7" sounds like supporting many, many additional users isn't onerous.
[20:02:43 CEST] <furq> libmfx isn't vital at all, it's for hardware encoding on newer intel cpus
[20:02:49 CEST] <furq> you could ask zeranoe to make builds without it
[20:02:54 CEST] <furq> i suspect you wouldn't be the first to ask him though
[20:04:00 CEST] <BtbN> I can totally understand why devs don't want to invest time to support 15 year old systems
[20:04:03 CEST] <BtbN> if it happens to work, fine
[20:04:30 CEST] <QH> So if I wanted to send a message to either the official project team or Zeranoe (without Twitter), how would I go about it? Is there an email address or web form?
[20:06:16 CEST] <BtbN> A build you downloaded somewhere from the internet is in no way official
[20:06:20 CEST] <BtbN> there are no official binaries
[20:06:35 CEST] <furq> yeah it has nothing to do with the ffmpeg devs
[20:06:45 CEST] <furq> zeranoe comes in here sometimes, idk how else to contact him
[20:06:45 CEST] <BtbN> And the official standpoint is that no efforts will be made to support unsupported versions of Windows.
[20:06:53 CEST] <furq> like i said, i'm pretty sure he's been asked this before
[20:07:12 CEST] <BtbN> it won't be sabotaged either, but will break more and more eventually
[20:09:26 CEST] <QH> Well, it looks like my next steps are to find out how I compile ffmpeg source code, then get a copy of the source and compile it without the library.
[20:09:48 CEST] <ChocolateArmpits> QH, using msys2 is probably the most straightforward approach
[20:09:51 CEST] <BtbN> or stop using an OS that doesn't receive security updates anymore
[20:10:22 CEST] <QH> @BtbN - that is definitely not the answer. I asked how to obtain for the OS, not change my OS.
[20:11:01 CEST] <ChocolateArmpits> I think workplaces carry a lot of XP hardware, so for more simpler tasks a supported binary would be more optimal than throwing out the machines
[20:11:48 CEST] <BtbN> Keeping to use XP or Vista, which do not get security updates, is highly risky and generally a really bad idea
[20:12:25 CEST] <QH> @BtbN - This is not a debate on the suitability of an OS I have no control over changing.
[20:20:12 CEST] <QH> @ChocolateArmpits - Thanks for your help. I've taken a quick look at msys2 and it seems simple enough, even if I end up only using it for this one task.
[20:22:10 CEST] <ChocolateArmpits> QH, just know that if you want to use the binaries outside of msys you'll have to carry all dependent dlls with the ffmpeg binary.
[20:23:11 CEST] <QH> Thanks, I'll remember that.
[20:25:15 CEST] <BtbN> msys dropped XP support btw.
[20:25:25 CEST] <BtbN> binaries built with it no longer run on XP
[20:25:32 CEST] <QH> I'm using Vista, so that should be fine.
[20:26:07 CEST] <BtbN> I think the last compiler to still support it is msvc, and even there you need to select a special xp toolchain
[21:22:00 CEST] <holla> ffmpeg -i IN.ts -map data-re -codec copy -f data OUT.data
[21:22:13 CEST] <holla> ^^ output file is empty
[21:22:47 CEST] <holla> so there's nothing in that 3rd stream, or is sth wrong with my command?
[21:23:59 CEST] <DHE> never answered my question. did you open it in wireshark?
[21:24:35 CEST] <BtbN> need to get it out of the .ts for that first
[21:24:53 CEST] <DHE> no
[21:25:11 CEST] <DHE> wireshark opens and parses mpegts directly
[21:27:10 CEST] <holla> DHE: i had to install wireshark first, but i did. it stuck at some 20% and finally crashed :(
[21:27:20 CEST] <DHE> too big?
[21:27:25 CEST] <holla> maybe
[21:27:37 CEST] <holla> 5gb
[21:27:53 CEST] <DHE> oh dear... okay. can you truncate the file to, say, 100 megabytes and try again? (make a copy obviously)
[21:28:38 CEST] <holla> of course - came to my mind just as i wrote to you ;)
[21:29:13 CEST] <holla> but how about my line? shouldn't it extract the data stream as well?
[21:31:55 CEST] <DHE> I don't know. what I'm suggesting is to use wireshark to examine the PMT directly and find out what type it is listed to have and what the stream descriptors say (if anything)
[21:32:59 CEST] <holla> fyi, ffmpeg -i IN.ts -t 00:05.00 -codec copy OUT.ts says video:24436kb audio:74665kb subtitle: 0kb other streams: 0kb
[21:33:23 CEST] <holla> so, it really seems like there's nothing in there
[21:33:47 CEST] <holla> but i'll now feed the cut to wireshark
[21:34:42 CEST] <BtbN> ffmpeg will most likely drop unknown data streams in a remux
[21:34:48 CEST] <BtbN> just cut the first 100MB of the file
[21:35:15 CEST] <holla> wireshark 's up now - where to look at?
[21:35:32 CEST] <DHE> put the filter "mpeg_pmt" into the filter text box at the top and hit Apply
[21:37:10 CEST] <holla> done. next?
[21:37:26 CEST] <DHE> click a chunk entry in the top. then expand the PMT info in the bottom. then expand the Stream fields. eg: "Stream PID=0x0420"
[21:37:49 CEST] <DHE> each one is one of the streams ffmpeg reports.
[21:37:57 CEST] <DHE> eg: "Stream type: AVC video stream as defined in ITU-T Rec. H.264 | ISO/IEC 14496-10 Video (0x1b)"    # this means H.264 video in this stream
[21:38:55 CEST] <holla> what i see is iso/iec 13818-1 pid=0x1000 cc=0
[21:39:24 CEST] <DHE> next noe is MPEG Program Map Table. that's the PMT
[21:39:27 CEST] <DHE> *next one
[21:41:20 CEST] <holla> i can't see anything in there which might identify that data?
[22:12:04 CEST] <dejdo> good evening everyone
[22:12:38 CEST] <dejdo> i am trying to draw text on video i am streaming from a uvc camera through ffserver, without success
[22:17:11 CEST] <dejdo> https://pastebin.com/iKu3aeXa
[22:17:43 CEST] <dejdo> when i'm streaming the -vf drawtext gets ignored. what am i doing wrong?
[22:20:15 CEST] <BtbN> you are very unlikely to find any help with ffserver related things, it's unmaintained and essentially dead.
[22:21:33 CEST] <dejdo> erm uh, thats bad news. any alternatives? How the good people stream webcameras nowadays?
[22:22:48 CEST] <DHE> I have a webcam running with HLS output, plus HLS.js for playing
[22:25:30 CEST] <DHE> ffmpeg converts from rtsp to HLS, obviously
[22:26:01 CEST] <dejdo> thanks (noises of frantic googling in the background)
[22:26:20 CEST] <BtbN> Or just use nginx rtmp
[22:26:57 CEST] <DHE> I stick with HLS out of personal expertise with it and a relative minimal of software required.
[22:27:27 CEST] <BtbN> it's pointless delay if you don't need it for browser playback
[22:28:17 CEST] <DHE> if you need close to realtime, yes you're right. if you don't, +
[22:28:42 CEST] <dejdo> thanks for both of you, i'll look into nginx/rtmp/ffmpeg. I would like to be it close to realtime.
[22:29:01 CEST] <DHE> then nginx-rtmp will be the better choice. HLS tends to have long delays, like 10-20 seconds
[22:30:53 CEST] <dejdo> thanks.
[22:31:04 CEST] <BtbN> it has quite exactly 3*segment_length of delay
[22:31:44 CEST] <dejdo> that sounds nice.
[22:32:41 CEST] <DHE> maybe, but I would suggest a segment size of around 5 seconds (4-8 range would be my personal preference) hence the 10-20 second delay I mentioned earlier
[22:33:30 CEST] <dejdo> but this is for another day, it's quite late here. Asked because of final desperation.
[22:33:39 CEST] <BtbN> Twitch uses 2 seconds now, and is pretty much at 6-7 seconds of delay
[22:33:45 CEST] <BtbN> they put quite a lot of work into that
[22:33:57 CEST] <DHE> wow, that's pretty aggressive
[22:35:01 CEST] <BtbN> it's also quite a quality hit due to the small gop
[22:49:23 CEST] <DHE> is 60 frames (assuming 30fps) really that bad for quality on h264?
[22:50:14 CEST] <BtbN> well, the longer between I frames the better
[22:51:02 CEST] <kazuma_> why btbn?
[22:51:21 CEST] <BtbN> Because they are big and steal bits
[22:51:29 CEST] <DHE> kazuma_: keyframes are large negatively affecting bitrate. and h264 doesn't support from quality deterioration from long periods without keyframes (older mpeg codecs did)
[22:51:49 CEST] <kazuma_> ahh ok
[22:52:17 CEST] <kazuma_> i assumed less i-frames = picture degradation and encoding artifacts
[22:52:31 CEST] <DHE> this is true for mpeg4 part2 (aka Xvid or divx)
[22:52:36 CEST] <DHE> but h264 does not
[22:52:39 CEST] <kazuma_> cool
[22:54:49 CEST] <DHE> I'm curious if there's some point of diminishing returns where paying the bitrate penalty for a keyframe isn't a serious concern for quality
[22:55:15 CEST] <BtbN> no
[22:55:49 CEST] <BtbN> for applications that can do that, you only send one I frame in the beginning, and then never again, or only on request because of a dropped package
[23:00:27 CEST] <DHE> hmm.. yeah I suppose that makes sense...
[23:01:45 CEST] <DHE> I mean in the sense of "no". I can't make use of 'smart' recovery
[00:00:00 CEST] --- Mon Jun 12 2017