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

[burek]

[00:37:16 CEST] <Tunabrain> Hi! Is there any way for expressions in the "drawbox" filter to depend on the current time stamp?
[00:37:44 CEST] <Tunabrain> From the docs it looks like the 't' variable is overwritten with the box thickness https://ffmpeg.org/ffmpeg-filters.html#drawbox
[00:49:58 CEST] <llogan> Tunabrain: not all filters support the same expressions
[00:52:13 CEST] <llogan> i don't think drawbox supports anything based on time
[00:52:35 CEST] <Tunabrain> Ah, I see
[00:52:36 CEST] <Tunabrain> Bummer
[00:53:17 CEST] <Tunabrain> My current workaround is to create a constant color source and then use overlay to draw a time-based rectangle from it
[00:53:36 CEST] <Tunabrain> It's pretty hacky, so a time-based drawbox solution would have been nice
[00:54:04 CEST] <xtina> kepstin: i checked what happens when my youtube live stream ends
[00:54:06 CEST] <xtina> the ffmpeg command does not end
[00:54:40 CEST] <xtina> but it does stop updating.. i.e. my logs don't show any new packets sent after the stream ends
[00:54:47 CEST] <xtina> but I still see the process ongoing with PS
[00:55:34 CEST] <xtina> if the other side of RTMP closes, should I expect the ffmpeg process to die or just to hang and stop?
[00:56:01 CEST] <llogan> Tunabrain: if you C you can give it a try implementing it. or submit a feature request to the bug tracker (and additionally offer a bounty if you prefer).
[00:56:06 CEST] <llogan> *know C
[00:57:47 CEST] <Tunabrain> If I have time I'll take a look at the source
[00:58:03 CEST] <xtina> i had wanted to restart ffmpeg if the process had died, but it seems i can't count on the ffmpeg process dying when the youtube live stream ends..
[00:59:58 CEST] <llogan> Tunabrain: if you do implement it feel free to send a patch to the ffmpeg-devel mailing list
[01:13:43 CEST] <xtina> does anyone know if a ffmpeg process dies when the rtmp connection fails?
[01:13:47 CEST] <xtina> (mine doesn't, i thought it would)
[01:13:59 CEST] <llogan> Tunabrain: looks like a somewhat related patch is on ffmpeg-devel for adding expr evaluation to an option in drawtext. it is still under review, but may give some clues: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209773.html (see "URL:" link at bottom for actual patch)
[01:14:25 CEST] <Tunabrain> Ah, thank you
[02:07:33 CEST] <xtina> hey, does anyone know why my ffmpeg cmd doesn't die even if my rtmp stream ends?
[02:10:17 CEST] <thebombzen> what do you mean by "ends"
[02:10:32 CEST] <thebombzen> and is ffmpeg the source or the sink
[02:10:36 CEST] <xtina> thebombzen: youtube live says "Stream Complete"
[02:10:59 CEST] <xtina> at this point, the stream won't take any new packets unless a brand new ffmpeg command is run
[02:11:13 CEST] <thebombzen> so you're streaming to youtube live with ffmpeg's rtmp output
[02:11:20 CEST] <thebombzen> but did you end the stream with youtube
[02:11:36 CEST] <xtina> nah, this happens if my wifi signal is too low for a long time
[02:11:43 CEST] <thebombzen> well okay
[02:11:46 CEST] <xtina> and youtube doesn't get packets for a while..
[02:11:49 CEST] <xtina> i suppose it ends the stream
[02:11:59 CEST] <thebombzen> so youtube closes the connection
[02:12:13 CEST] <thebombzen> but why should you expect ffmpeg to end necessarily
[02:12:22 CEST] <xtina> and i would like to be aware of this on the Pi side, so the pi automatically attempts to restart the stream
[02:12:22 CEST] <thebombzen> it's not like a pipe where breaking one side breaks the other
[02:12:34 CEST] <xtina> i see, a message from kepstin earlier gave me this impression
[02:12:47 CEST] <thebombzen> probably you should monitor your network
[02:12:52 CEST] <thebombzen> beause ffmpeg won't be ablet o restart itself anyway
[02:12:53 CEST] <xtina> "xtina: that's strange - with rtmp, it's a tcp connection, so when youtube stops accepting video it should eventually get a connection reset by peer which causes ffmpeg to exit ["
[02:12:54 CEST] <kepstin> this is rtmp, over a tcp connection
[02:13:02 CEST] <thebombzen> kepstin: yea that's what I had thought
[02:13:05 CEST] <thebombzen> because it's tcp
[02:13:21 CEST] <xtina> i can't, i'm moving around with my device, wifi drops will happen
[02:13:23 CEST] <thebombzen> but according to xtina ffmpeg' won't exit when the output tcp cxn ends
[02:13:23 CEST] <kepstin> it *should* break the other side - when google receives a packet after closing the connection, they should send back a reset to tell you that it's invalid
[02:13:37 CEST] <xtina> when this happens i'd just like the Pi to know and automatically end any currently running ffmpeg, then restart ffmpeg
[02:13:46 CEST] <xtina> should be doable via script, i would think, but just wondering if there's an elegant soluton
[02:13:58 CEST] <kepstin> so either they didn't actually close the connection on their end, in which case you can't actually tell when this has gone wrong easily, or... ? some other bug :/
[02:14:01 CEST] <xtina> otherwise i have a hacky way of doing it (icheck ffmpeg log doesn't grow over a certain amt of time)
[02:14:52 CEST] <xtina> hmm
[11:24:33 CEST] <thebombzen> is there any plan to support BPG images or any other "new image"
[11:24:55 CEST] <thebombzen> I find it amusing that FFmpeg doesn't support Fabrice Bellard's own image format
[11:27:03 CEST] <furq> bpg is technically nice but practically useless because of the hevc tax
[11:27:34 CEST] <furq> flif might be nice but is the bitstream frozen yet
[11:28:02 CEST] <thebombzen> I think so
[11:28:09 CEST] <thebombzen> also who's the current lead maintainer of ffmpeg?
[11:28:22 CEST] <thebombzen> is it carl eugen or michael niedermayer or someone else
[11:28:33 CEST] <furq> pretty sure michaelni is still the maintainer
[11:29:03 CEST] <furq> bpg lossless isn't that impressive according to the flif site
[11:29:11 CEST] <furq> although i guess you wouldn't want to use it lossless
[11:29:15 CEST] <thebombzen> eh, I'm more interested in lossy tbh
[11:29:27 CEST] <furq> i'm mostly interested in webp for lossless
[11:29:39 CEST] <furq> it saves about 40% over png on average
[11:29:43 CEST] <thebombzen> mostly because I feel like "why are we using jpeg as our lossy format in 2017"
[11:29:54 CEST] <furq> jpg sucks but my preferred answer to that is "don't use jpeg"
[11:29:54 CEST] <thebombzen> flif claims it's better than webp lossless
[11:30:00 CEST] <furq> yeah it does
[11:30:04 CEST] <furq> it wouldn't surprise me
[11:30:06 CEST] <thebombzen> the problem with "don't use jpeg" is there isn't really any better lossy alternatives
[11:30:22 CEST] <furq> well i mean my preferred solution is to not use lossy images
[11:30:29 CEST] <thebombzen> the alternative is usually "use png" which is often too big and impractical for something like a photograph
[11:30:37 CEST] <thebombzen> png isn't even dct-based so sucks for realworld images
[11:30:49 CEST] <furq> i don't have a camera that doesn't output jpg, so recompressing is only going to make things worse
[11:30:52 CEST] <furq> and i don't do any webdev
[11:31:18 CEST] <thebombzen> well good cameras output RAW as well
[11:31:23 CEST] <furq> sure
[11:31:25 CEST] <furq> i don't have one though
[11:31:30 CEST] <furq> i'm not saying it's useless, just that i don't care
[11:31:40 CEST] <thebombzen> ah you're saying that realworld images end up as jpegs
[11:31:47 CEST] <thebombzen> most of the time at least
[11:31:58 CEST] <thebombzen> so in my experiences I actually find jpegs are really nice if you don't care about quality
[11:32:14 CEST] <furq> i don't have any source of lossless images that take enough space for me to want to lossily compress them
[11:32:19 CEST] <thebombzen> jpeg quality 95 still has some ringing but it's not noticable unless your image is flat or a screengrab
[11:32:43 CEST] <thebombzen> because of that I like jpeg in that a 2 MB png might be like a 300k jpeg
[11:32:54 CEST] <thebombzen> which is very convenient w/r/t, say, mpv's screenshot functionality
[11:33:15 CEST] <thebombzen> cause if you take a lot of screenshots, 2 MB per gets big fast and 95 quality jpeg does not
[11:33:48 CEST] <furq> how many screenshots are we talking here
[11:33:48 CEST] <thebombzen> plus I would just extract the lossy frames... but they're H.264 so even if they're Iframes you still can't use them for anything
[11:34:16 CEST] <furq> because i have a bunch of useless directories that are above 2GB that i could delete but have no incentive to
[11:36:08 CEST] <thebombzen> how many screenshots?
[11:36:12 CEST] <thebombzen> about 1300
[11:36:20 CEST] <thebombzen> al together are about 285 megabytes
[11:36:31 CEST] <furq> at the risk of sounding like a javascript developer, 2.6GB isn't really very much
[11:36:51 CEST] <furq> or probably half that with flif
[11:37:31 CEST] <thebombzen> yea but also you have to take into account compression time
[11:37:42 CEST] <thebombzen> pngs take much longer to save than jpegs, even with mozjpeg
[11:37:47 CEST] <thebombzen> or equivalent
[11:38:02 CEST] <thebombzen> one 720p png file might take several seconds to compress at -9
[11:38:08 CEST] <thebombzen> (1280x720 that is)
[11:38:12 CEST] <furq> save to tga then batch recompress overnight
[11:38:40 CEST] <thebombzen> does mpv even support screenshotting as targa
[11:38:43 CEST] <furq> no idea
[11:38:57 CEST] <furq> i'd hope so if it has a gl backend
[11:39:04 CEST] <thebombzen> nope just png and jpeg
[11:39:07 CEST] <furq> lame
[11:39:45 CEST] <thebombzen> I could use png -0 probably
[11:39:48 CEST] <thebombzen> might have the same effect
[11:40:02 CEST] <furq> it won't be as fast as tga but it should be fast enough
[11:40:08 CEST] <thebombzen> but you still run into the problem of huge filesize
[11:40:24 CEST] <furq> well yeah that's the "batch recompress overnight" bit
[11:40:26 CEST] <thebombzen> and even if you batch recompress them to png, you run into issues where png files are still big
[11:40:33 CEST] <furq> i meant to webp or flif
[11:40:41 CEST] <thebombzen> well then they're useless
[11:40:54 CEST] <thebombzen> because if you were to upload them to the internet, nobody could read them
[11:41:01 CEST] <thebombzen> hell right now I can't read a flif file
[11:41:07 CEST] <furq> why are you uploading 1300 files to the internet
[11:41:23 CEST] <thebombzen> I am not
[11:41:29 CEST] <thebombzen> but if one file is 2 MB then ten of them is 20 MB
[11:41:35 CEST] <furq> i wonder what imgur makes of flif
[11:41:41 CEST] <furq> idk if i even have anything that writes them
[11:41:42 CEST] <thebombzen> so if I want to say, put ten screenshots together
[11:41:48 CEST] <thebombzen> or UL an imgur album or something
[11:42:00 CEST] <thebombzen> 20 MB is an enormous amount of data for a user to download to view all the images
[11:42:11 CEST] <furq> imgur would recompress anything other than png or jpeg anyway
[11:43:08 CEST] <thebombzen> yea
[11:43:13 CEST] <thebombzen> plus, flif has no support
[11:43:21 CEST] <furq> lol
[11:43:35 CEST] <furq> ok so if you open the file picker on imgur it lists webp as a supported format
[11:43:39 CEST] <furq> but then it does nothing if you try to uplaod one
[11:43:43 CEST] <furq> thanks imgur you piece of shit
[11:44:15 CEST] <thebombzen> flif it has no support in libavcodec, gimp, krita, photoshop, any browser, or even irfanview
[11:44:28 CEST] <thebombzen> I'll stick with webp for now at least
[11:44:41 CEST] <furq> lossless webp is good
[11:44:49 CEST] <furq> i've not really used lossy webp much but it can't be worse than jpeg
[11:46:26 CEST] <thebombzen> firefox doesn't even support webp does it
[11:55:17 CEST] <furq> yeah it does
[11:56:01 CEST] <furq> oh
[11:56:06 CEST] <furq> no it doesn't, but it's planned
[11:56:32 CEST] <thebombzen> furq: what preset would you recommend for libwebp lossless for animation
[11:56:39 CEST] <thebombzen> 2D animation
[11:56:52 CEST] <thebombzen> (I'd assume photo for 3D animation)
[11:56:52 CEST] <furq> i don't think you're supposed to use the presets
[11:56:58 CEST] <furq> for lossless, anyway
[11:57:01 CEST] <furq> i just used cwebp -z 9
[11:57:59 CEST] <thebombzen> how good is -near_lossless
[11:58:10 CEST] <thebombzen> which just prefilters and then uses -lossless
[12:06:44 CEST] <furq> shrug
[12:14:00 CEST] <thebombzen> furq: I just did a quick "flif vs webp lossless" test
[12:14:09 CEST] <thebombzen> my heuristic evidence is that flif is about 10% smaller than webp
[12:14:32 CEST] <thebombzen> with about 96% less support
[14:20:58 CEST] <thebombzen> what is the practical difference of encoding bgr0 versus rgb24 or bgr24
[14:21:05 CEST] <thebombzen> does bgr0 provide "better alignment" or something
[14:22:19 CEST] <BtbN> Whatever endianess you prefer
[16:22:29 CEST] <kepstin> thebombzen: bgr0 is aligned to 32bits, a power of 2, which can make it faster in some circumstances.
[16:22:49 CEST] <thebombzen> so "yes"
[16:23:08 CEST] <thebombzen> does it take up more space though? obviously in raw but I feel like encoded it shouldn't
[16:23:28 CEST] <kepstin> well, yeah, bgr0 is 32bits, rgb24 is 24bits
[16:23:55 CEST] <kepstin> but 8 bits of the bgr0 are unused - there's only 24bits of data in it - so compressed? well, it depends on the compression format...
[16:24:07 CEST] <kepstin> but i'd expect that wouldn't make a difference
[16:29:27 CEST] <thebombzen> I'd think not but it depends on the encoder I guess
[16:29:33 CEST] <thebombzen> H.264 is probably good enough that it won't matter
[16:30:10 CEST] <thebombzen> another question: ffv1 says in the spec it's intra-only but it's not listed as intra-only on ffmpeg -codecs
[16:30:13 CEST] <thebombzen> is that a mistake
[16:36:15 CEST] <kepstin> i'm pretty sure that x264 in rgb mode encodes it in planar, regardless of the input pixel format
[16:40:29 CEST] <thebombzen> x264 doesn't take gbrp though
[16:41:12 CEST] <thebombzen> if you try to feed it gbrp at least with libavcodec's wrapper, it'll automatically insert format=rgb24
[16:41:16 CEST] <thebombzen> and encode rgb24
[16:41:30 CEST] <kepstin> i bet that's just some quirk of the adapter interface :/
[16:42:26 CEST] <kepstin> rgb in x264 is encoded in pretty much the same way as yuv444
[16:42:45 CEST] <thebombzen> yuv444 or yuv444p?
[16:42:57 CEST] <thebombzen> interestingly enough, it reported as encoding it as bgr0, but if I then use ffmpeg -i encoded_file it reports gbrp
[16:43:13 CEST] <thebombzen> it seems like the libavcodec wrapper should allow gbrp as an input colorspace to libx264rgb
[16:43:46 CEST] <thebombzen> currently it only uses bgr0, rgb24, or bgr24
[16:45:30 CEST] <kepstin> thebombzen: for some reason, the x264 library only accepts rgb data input in packed formats. no idea why. I assume it unpacks it inside the encoder.
[16:48:08 CEST] <kepstin> yep, that's what it does. I wonder why they don't support planar rgb input
[16:48:12 CEST] <kepstin> eh, whatever.
[18:05:23 CEST] <zeryx> hmm, I want to concat frames together, but I also want to downscale the quality at the same time using a video compression algorithm
[18:05:27 CEST] <zeryx> this is my line right now:
[18:05:29 CEST] <zeryx> ffmpeg -framerate 3 -c:v libx264 -preset veryfast -crf 30 -i 8837001e-39e4-4795-b935-18769ee2e709-%05d.png outfile.mp4
[18:05:38 CEST] <zeryx> which returns this as an error: Unknown decoder 'libx264'
[18:06:03 CEST] <zeryx> how far off the mark am I/
[18:06:22 CEST] <kepstin> zeryx: ffmpeg options are positional - they do different things depending on where in the command they are
[18:06:35 CEST] <zeryx> yea I remember that, which makes things really complicated
[18:06:44 CEST] <zeryx> any ideas on where things should go?
[18:06:49 CEST] <kepstin> options configuring inputs go before the input, options configuring outputs go before the output (and after all inputs)
[18:06:52 CEST] <zeryx> (maybe the codec stuff is after the -i?)
[18:06:57 CEST] <zeryx> oh
[18:07:04 CEST] <kepstin> so leave the framerate before the input, move everything else after
[18:07:52 CEST] <zeryx> oh neat that worked
[18:07:55 CEST] <zeryx> thanks!
[21:09:13 CEST] <goran> Hi, anyone available for a little help?
[21:09:47 CEST] <goran> I m trying to extract x seconds from every minute and produce a video. For example: from a 6 minute video, i want to take 1st second from the 1st minute, then 1st second from the 2nd minute etc (or more clearly, take 00:00:01, 00:01:01, 00:02:01 ...) and construct a new video.
[21:19:08 CEST] <kepstin> goran: that sort of thing can be probably by done with the 'select' video filter, but getting the expression correct would be kinda tricky.
[21:19:55 CEST] <kepstin> I guess not too bad if you have constant framerate, then it's just "check if frame number is a multiple of x"
[21:21:54 CEST] <goran> for now i m just using -ss and -t to extract 30 seconds starting from 10th second for example
[21:25:22 CEST] <thebombzen> goran: try -vf 'select=between(mod(t\,60)\,0\,1)'
[21:26:02 CEST] <thebombzen> t is the time in seconds and mod(t, 60) is the time mod 60, i.e. just the second counter w/o minutes or hours etc.
[21:26:03 CEST] <kepstin> yeah, that's probably a good start. Might need to clean up the timestamps afterwards, using e.g. ',setpts=N'
[21:26:24 CEST] <kepstin> (depending on the timebase, framerate)
[21:26:34 CEST] <thebombzen> yea the timestamps will be off
[21:26:48 CEST] <thebombzen> if R is the input framerate, then you can follow it up with setpts=N/R/TB
[21:26:55 CEST] <thebombzen> where R is the actual framerate (perhaps 24)
[21:27:15 CEST] <thebombzen> this gets much mored difficult with audio (which you should probably do separately)
[21:27:58 CEST] <goran> audio is excluded from the video
[21:28:09 CEST] <thebombzen> good cause that makes it easier
[21:41:00 CEST] <hurzl1> how can I force/override the input sample rate?
[21:45:39 CEST] <alexpigment> hurzl1: just put -r (framerate) prior to the -i [infile]
[21:45:56 CEST] <alexpigment> e.g. -r 29.97
[21:48:36 CEST] <kepstin> hurzl1: or do you mean audio sample rate?
[21:48:44 CEST] <alexpigment> oh duh
[21:48:54 CEST] <alexpigment> ignore me. doing too many things at once here
[21:49:04 CEST] <alexpigment> -ar is the sample rate
[21:49:16 CEST] <hurzl1> but only works for stdin?
[21:49:21 CEST] <kepstin> hurzl1: if you're inputting raw audio into ffmpeg, use the -sample_rate input option to set it (default is 44100)
[21:49:45 CEST] <kepstin> (and you might need -channels too)
[21:50:21 CEST] <hurzl1> i have an video where the sound is declared 48000 and runs to fast, so I suspect the real rate is 44100
[21:50:30 CEST] <kepstin> if you're inputting a format with a header and want to override it... hmm. might be able to do that with filters
[21:51:20 CEST] <kepstin> in this case, "-af asetrate=48000" would do it I think
[21:51:56 CEST] <kepstin> or, er, i got that backwards. "-af asetrate=44100" :)
[21:54:20 CEST] <hurzl1> that works but a and v run out of sync :(
[21:54:36 CEST] <kepstin> well, yes, it slowed down the audio without making any changes to the video :)
[21:56:12 CEST] <hurzl1> they are out of sync in the input file already, with mplayer. with mpv everything runs too fast
[21:56:56 CEST] <kepstin> weird. must be something really strange about your file then
[21:57:30 CEST] <hurzl1> it is the stream arte sends via dvb-t2
[21:59:23 CEST] <hurzl1> Stream #0:0[0xd2]: Video: hevc (Main) ([36][0][0][0] / 0x0024), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 50 tbc
[21:59:23 CEST] <kepstin> should be mpeg-ts then, which I'd expect to be fine... :/
[21:59:23 CEST] <hurzl1>     Stream #0:1[0xdc](ger): Audio: aac_latm (LC) ([17][0][0][0] / 0x0011), 48000 Hz, 5.1, fltp
[22:00:02 CEST] <kepstin> yeah, 50fps video & 48kHz audio is what i'd expect in a dvb broadcast in europe
[22:00:09 CEST] <kepstin> weird that it's hevc tho
[22:00:15 CEST] <alexpigment> yeah, hevc caught my eye too
[22:00:34 CEST] <alexpigment> is it possible that the system just can't keep up with HEVC? or is doing hardware decoding and needs updated drivers?
[22:00:46 CEST] <hurzl1> new HD 1920x1080, somehow it's broken. all other stations work fine
[22:01:00 CEST] <alexpigment> are all other stations AVC (H.264)?
[22:02:07 CEST] <kepstin> yeah, my guess might be that the players aren't decoding the video fast enough or something? mpv and mplayer should print console warnings if that happens tho
[22:02:11 CEST] <hurzl1> different audio format: Stream #0:0[0x96a]: Video: hevc (Main) ([36][0][0][0] / 0x0024), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 50 tbc
[22:02:12 CEST] <hurzl1>     Stream #0:1[0x974](ger): Audio: eac3 ([6][0][0][0] / 0x0006), 48000 Hz, stereo, fltp, 256 kb/s
[22:02:48 CEST] <hurzl1> mplayer prints many [aac_latm @ 0x8058a4250]Number of bands (11) exceeds limit (3).
[22:04:21 CEST] <hurzl1> mpv and mplayer cannot decode aac_latm 5.1?
[22:04:42 CEST] <alexpigment> i saw this: https://trac.ffmpeg.org/ticket/4544
[22:04:47 CEST] <alexpigment> just closed recently
[22:06:45 CEST] <alexpigment> i have zero experience with AAC_LATM - at least i don't recall using it - kepstin probably knows more about it
[22:06:49 CEST] <hurzl1> so i apply that patch to ffmpeg and it should work?
[22:07:00 CEST] <kepstin> i've never seen any latm stuff :/
[22:07:53 CEST] <alexpigment> but yeah, if there's a patch from February, it's worth a shot
[22:08:42 CEST] <Threads> kepstin parts of the EU has changed from h264 to hevc
[22:08:50 CEST] <Threads> i think is going to be next
[22:08:57 CEST] <Threads> i think france is going to be next
[22:09:04 CEST] <alexpigment> man, europe is always on the cutting edge with broadcast standards. i guess because it's all satellite based these days...
[22:09:17 CEST] <dystopia_> only 4k stuff is broadcasting in hevc
[22:09:31 CEST] <dystopia_> everything else is h264/mpeg2
[22:09:32 CEST] <alexpigment> dystopia: not according to hurzl1's file up there
[22:09:57 CEST] <dystopia_> hmm
[22:10:02 CEST] <alexpigment> sadly, american OTA doesn't even have H.264 yet :(
[22:10:17 CEST] <alexpigment> nor do most cable companies, for that matter
[22:12:00 CEST] <kepstin> the satellite tv providers here are still using mpeg2 for most stuff, my parents old mpeg2 box still works fine :/
[22:12:14 CEST] <alexpigment> kepstin: i was pretty sure directv and dish used H.264
[22:12:17 CEST] <hurzl1> patch doesn't fit my ffmpeg-3.2.4
[22:12:21 CEST] <BtbN> Well, everything that's SD, for legacy reasons
[22:12:21 CEST] <alexpigment> maybe they're sending out both for compatibility
[22:12:36 CEST] <BtbN> they definitely don't
[22:13:09 CEST] <alexpigment> kepstin: does your parents' old box just do SD channels?
[22:13:15 CEST] <dystopia_> you can modify the header aac adts without transcoding it hurzl1 and it should work ok
[22:13:25 CEST] <kepstin> alexpigment: no, tops out at 1080i, does hdtv channels
[22:13:31 CEST] <alexpigment> interesting
[22:13:42 CEST] <alexpigment> i was pretty sure they had all switched to H.264. guess i was wrong about that
[22:13:46 CEST] <kepstin> (this is shaw direct in canada)
[22:13:49 CEST] <alexpigment> ahhh
[22:13:55 CEST] <alexpigment> well
[22:13:59 CEST] <alexpigment> *canada*
[22:14:02 CEST] <alexpigment> there's your problem ;)
[22:14:09 CEST] <hurzl1> dystopia_: modify how?
[22:14:45 CEST] <kepstin> lets see, I think they have a DSR319 from when the service was still called "Star Choice"
[22:14:48 CEST] Action: kepstin looks up the specs
[22:15:15 CEST] <alexpigment> dystopia are you talking about the -bsf:a aac_adtstoasc parameter?
[22:15:24 CEST] <kepstin> hmm, no, must be older, it's a full-size box.
[22:15:26 CEST] <alexpigment> i'm not sure that applies here
[22:16:00 CEST] <dystopia_> im not sure you can do it with ffmpeg but on windows you can use videoredo
[22:16:05 CEST] <alexpigment> kepstin: i suppose as long as they're not starving the bandwidth, it's fine
[22:16:12 CEST] <dystopia_> save as > options > tick convert latm to adts aac
[22:16:20 CEST] <kepstin> alexpigment: they're def. starving bitrate on some of the channels
[22:16:25 CEST] <Threads> -acodec aac
[22:16:38 CEST] <alexpigment> fwiw, i wholly endorse VideoRedo. i use that software more than just about anything else
[22:17:14 CEST] <kepstin> ah, it's an HDPVR 530. lets see if I can find the spec sheet...
[22:17:28 CEST] <alexpigment> kepstin: yeah, having to work with video so much and keeping an eye out for quality, it's really really hard to watch bandwidth-starved MPEG-2. and that's most of what you see on Time Warner Cable :(
[22:18:35 CEST] <kepstin> lets see, i think that's a "DSR530" in motorola model numbers
[22:18:55 CEST] <Threads> Stream mapping:
[22:18:55 CEST] <Threads>   Stream #0:1 -> #0:0 (aac_latm (native) -> aac (native))
[22:19:09 CEST] <Threads> is that what you want frrom aac_latm to aac ?
[22:19:39 CEST] <Threads> i just use this
[22:19:41 CEST] <Threads> ffmpeg -i fileinput -vn -acodec aac -strict -2 -bsf:a aac_adtstoasc -map 0:1 -map_metadata -1 -movflags faststart -y test.m4a
[22:20:24 CEST] <alexpigment> Threads - I don't think you need to re-encode the audio with the bsf
[22:20:37 CEST] <alexpigment> i think you can -c:a copy
[22:21:24 CEST] <Threads> that doesnt work
[22:21:35 CEST] <Threads> [ipod @ 05f997c0] Could not find tag for codec aac_latm in stream #0, codec not currently supported in container
[22:21:35 CEST] <Threads> Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument
[22:21:35 CEST] <Threads> Stream mapping:
[22:21:35 CEST] <Threads>   Stream #0:1 -> #0:0 (copy)
[22:21:35 CEST] <Threads>     Last message repeated 1 times
[22:22:35 CEST] <alexpigment> well what about just ffmpeg -i infile -c:v copy -c:a copy -bsf:a aac_adtstoasc output.ts
[22:22:46 CEST] <alexpigment> or output.mp4
[22:23:08 CEST] <kepstin> hmm, they don't list supported codecs anywhere for the Motorola DVR 530, but the 6xx models all advertise "mpeg 4" support, so I guess it was mpeg2-only (might have supported upgrading with a card tho)
[22:23:38 CEST] <alexpigment> kepstin: mpeg-4 *could* mean they had a deal with DivX in the works ;)
[22:24:00 CEST] <alexpigment> MPEG-4 is so confusing when used generically like that
[22:24:05 CEST] <kepstin> oh, it is in the spec sheet, "MPEG-4 support can be upgraded in the field through a customer-installable module."
[22:24:30 CEST] <alexpigment> yeah, but does that mean H.264?
[22:25:07 CEST] <kepstin> probably, h264 is also known as "mpeg-4 avc" and I don't think mpeg-4 asp was ever used in broadcast
[22:25:33 CEST] <alexpigment> i agree, but who knows what motorola was up to back then ;)
[22:25:40 CEST] <hurzl1> Codec 'aac_latm' (86066) is not supported by the bitstream filter 'aac_adtstoasc'. Supported codecs are: aac (86018)
[22:25:40 CEST] <hurzl1> Error initializing bitstream filter: aac_adtstoasc
[22:26:03 CEST] <hurzl1> ... using -c:a copy -bsf:a aac_adtstoasc
[22:26:22 CEST] <alexpigment> yeah, i didn't think that bsf was applicable anyway (as i mentioned when talked to dystopia)
[22:26:58 CEST] <alexpigment> but Threads is saying it works when re-encoding with his parameters, so it's worth a shot
[22:28:05 CEST] <hurzl1> that patch is from feb, there should be an ffmpeg release that contains it
[22:29:15 CEST] <alexpigment> i don't know much about commits and when they get merged into the nightlies to be perfectly honest
[22:29:18 CEST] <alexpigment> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=1fce67d6403a4540181f6ed05abf5b3edd4ef014
[22:29:32 CEST] <alexpigment> can anyone tell if that's been pushed to the nightlies?
[22:30:20 CEST] <hurzl1> on https://ffmpeg.org/download.html the latest is 3.2.4
[22:31:50 CEST] <kepstin> lets see... apparently the shaw/star-choice dvr 530 boxes never received the mpeg4 upgrade cards, shaw decided to release a new receiver version instead. cheaper for them apparently.
[22:32:04 CEST] <hurzl1> that patch is 3 days after that release ;(
[22:34:13 CEST] <alexpigment> hurzl1: 3.2.4 is the last official release
[22:34:27 CEST] <alexpigment> you can get a newer ("non-stable") version though
[22:34:34 CEST] <alexpigment> what OS are you on?
[22:35:12 CEST] <hurzl1> FreeBSD
[22:35:32 CEST] <alexpigment> so many linux people on here at all times :) i feel like i'm the only windows user sometimes...
[22:35:39 CEST] <hurzl1> many patches to adjust ...
[22:36:23 CEST] <Threads> you can always be a hybrid
[22:36:37 CEST] <Threads> be a windows/linux user
[22:37:08 CEST] <alexpigment> hurzl1 i don't know what repos or download sites there are for getting newer builds for freebsd
[22:37:15 CEST] <alexpigment> aside from just building your own
[22:38:14 CEST] <hurzl1> none the ports tree has 3.2.4 and some patches for that
[22:38:17 CEST] <alexpigment> Threads: i was mostly kidding. i use ubuntu for a few projects here and there. i guess i just feel like if you're going to work on a lot of video projects and aren't dealing with strictly broadcast/film content, windows is the only option
[22:38:28 CEST] <hurzl1> will try to build the git version
[22:39:02 CEST] <dystopia_> windows is a must imo
[22:39:36 CEST] <dystopia_> dvbviewer, to watch and record tv, video redo to cut and edit, ffmpeg to encode
[22:39:50 CEST] <dystopia_> trying to replicat the workchain on nix is far too much hasstle
[22:40:13 CEST] <alexpigment> dystopia - replace dvbviewer with windows media center and I'm in the same workflow (at least for tv archiving)
[22:40:51 CEST] <alexpigment> but there are so many other crucial windows-only tools when working with video
[22:41:25 CEST] <alexpigment> not to mention driver support when you're talking about various video capture hardware
[22:41:46 CEST] <alexpigment> anyway, end mini rant ;)
[22:41:52 CEST] <dystopia_> :p
[22:54:58 CEST] <hurzl1> mplayer is now in sync!
[22:55:27 CEST] <hurzl1> just the message "aac_latm @ 0x805a108e0]audio config changed" twice a second
[22:57:15 CEST] <alexpigment> nice
[22:57:17 CEST] <alexpigment> ;)
[22:58:34 CEST] <hurzl1> now mpv and mplayer are the same speed
[23:00:17 CEST] <alexpigment> does anyone know what -lmin and -lmax do? and what their valid ranges are?
[23:00:36 CEST] <alexpigment> all i can find out is that they're deprecated (but still work) and the private encoder options are recommended instead
[23:00:54 CEST] <alexpigment> i don't know what it does enough to know the equivalent private encoder options are (mpeg2video in this case)
[23:07:19 CEST] <kepstin> alexpigment: the private options on the mpeg2video encoder are named "lmin" and "lmax"; if you're using the cli you can just ignore the warning
[23:07:43 CEST] <kepstin> as for what they do... ? who knows.
[23:08:13 CEST] <alexpigment> kepstin, yeah i was just about to write back that i was looking in the wrong codec section under the full documentation
[23:08:16 CEST] <alexpigment> sorry about that
[23:08:49 CEST] <alexpigment> i saw some recommendations to use different values, and this got rid of the 'pulsing' macroblocks i was seeing, but completely blew the buffer
[23:09:24 CEST] <alexpigment> i have a feeling that the pulsing just goes away with higher bitrates, so it's nothing special about lmin/lmax since the values i was trying were leading to higher bitrates
[23:09:52 CEST] <alexpigment> i really don't know why some mpeg-2 encoders cause pulsing like that and other don't
[23:10:09 CEST] <Tatsh> anyone familiar with 2pass encoding with nvenc?
[23:10:15 CEST] <kepstin> all i can see is that it's related the qp selection vbr encoding
[23:10:22 CEST] <alexpigment> nvenc 2pass is actually just 1 pass
[23:10:26 CEST] <Tatsh> ok
[23:10:30 CEST] <kepstin> Tatsh: I looked it up yesterday. it's just slightly less sucky 1pass.
[23:10:49 CEST] <Tatsh> so if i do -preset slow is it worthwhile compared to medium?
[23:10:51 CEST] <kepstin> Tatsh: https://gist.githubusercontent.com/kepstin/6672f5a0bc5e26c304e671c828a23d1b/raw
[23:10:59 CEST] <Tatsh> and it is just one pass, not having to invoke ffmpeg twice?
[23:11:28 CEST] <kepstin> basically, "2pass" mode in nvenc is like 1pass mode in most software codecs, and "1pass" mode is just kinda bad.
[23:11:37 CEST] <alexpigment> Tasch: based on my experience, NVENC encodes fast enough on modern chips that it's safe to do the slower presets. YMMV
[23:11:54 CEST] <BtbN> it was always safe to just use the slowest
[23:12:00 CEST] <alexpigment> 'safe' is the wrong word
[23:12:25 CEST] <alexpigment> i meant that it's better to use the slower presets because it's still very fast in my tests
[23:12:56 CEST] <alexpigment> granted i'm testing on an Nvidia 1060
[23:14:03 CEST] <kepstin> alexpigment: "pulsing" behaviour on videos usually just happens when you have vbv constraints that cause keyframes to be encoded at lower quality than predicted frames, right? So some encoders, with some settings, might lower quality of non-keyframes to match keyframes, I guess...
[23:15:17 CEST] <alexpigment> kepstin: that description makes perfect sense. thanks for the info
[23:15:42 CEST] <Tatsh> just want to make sure i have the right command
[23:15:48 CEST] <Tatsh> with two invocations of ffmpeg, -pass 1/2
[23:16:21 CEST] <kepstin> Tatsh: nvenc doesn't support a real two pass mode, using the "2pass" option on it just gives you a less bad quality single pass mode.
[23:17:10 CEST] <Tatsh> -preset slow automatically sets -2pass right?
[23:17:20 CEST] <iive> no
[23:17:23 CEST] <BtbN> yes
[23:17:32 CEST] <iive> oh, sorry
[23:17:37 CEST] <iive> it's nvenc
[23:18:27 CEST] <Tatsh> https://gist.github.com/Tatsh/60b3ab945ab9e5f24c5784768d60b260
[23:18:55 CEST] <BtbN> I'm not sure nvenc even supports baseline
[23:18:59 CEST] <Tatsh> it does
[23:19:00 CEST] <BtbN> Why would you want that? It's bad
[23:19:07 CEST] <Tatsh> compatibility?
[23:19:12 CEST] <BtbN> with what?
[23:19:19 CEST] <Tatsh> everything i come across i guess
[23:19:32 CEST] <BtbN> Everything you come accross will most likely play high just fine
[23:19:33 CEST] <Tatsh> i mean realistically i own good players
[23:19:44 CEST] <Tatsh> ok
[23:19:48 CEST] <BtbN> main and baseline are seriously bad
[23:19:53 CEST] <BtbN> and nvenc is already bad enough
[23:20:00 CEST] <alexpigment> i think the last baseline-only device i worked with was an iphone 3GS
[23:21:06 CEST] <bre> Hello. I have a variable frame rate video file. There is a delay of over 30 seconds between some frames. Can I transcode the video and reduce all delays between frames over a certain value, say 1 second, to that value? This would mean the maximum gap or delay between any 2 consecutive frames would be 1 second.
[23:21:12 CEST] <Tatsh> by default i think ffmpeg does high profile
[23:21:39 CEST] <kepstin> bre: yes, with careful use of the setpts filter (I assume you have no audio?)
[23:22:00 CEST] <bre> kepstin: yes, no audio
[23:22:02 CEST] Action: kepstin is off now tho
[23:22:22 CEST] <bre> :) ok thanks kepstin
[23:22:32 CEST] <kepstin> bre: the setpts filter expression knows the pts and time of the current and previous frames, so you should be able to do the calculation with that info
[23:22:59 CEST] <Tatsh> i can do high444 or i can do high -level 5.1
[23:23:03 CEST] <Tatsh> any opinions?
[23:23:25 CEST] <bre> I shall look into it kepstin. Thank you very much
[23:23:46 CEST] <Tatsh> real targets: web browser on modern system, ipad 4+
[23:23:55 CEST] <alexpigment> Tatsch: regarding the slow preset on Nvenc, i just did another comparison on my end transcoding a 1080p60 MPEG-4. libx264 at veryfast transcoded at 1m17s. Nvenc at slow transcoded at 17s . for reference, my CPU is a Core i7 3770 (4 cores, 8 threads)
[23:24:16 CEST] <alexpigment> don't do high444
[23:24:22 CEST] <alexpigment> or level 5.1
[23:24:43 CEST] <BtbN> just don't specify it at all
[23:24:53 CEST] <alexpigment> you want to do high (4:2:0) and level 4.0 for 1080p. it's better to leave the level at auto
[23:24:58 CEST] <Tatsh> ok
[23:25:07 CEST] <BtbN> there is no need to limit the level
[23:25:11 CEST] <BtbN> Leave the parameters alone
[23:25:15 CEST] <Tatsh> the content is 1080p but it's from a relatively crappy camera that saves in mjpeg AVI
[23:25:26 CEST] <alexpigment> BtbN for some devices, there's definitely a need to
[23:25:40 CEST] <BtbN> the encoders will use the lowest it can by default
[23:25:57 CEST] <alexpigment> 4.1 is obviously just a bitrate difference compared to 4.0, but some devices will refuse 4.1
[23:26:20 CEST] <alexpigment> BtbN if the decoder jumps to 30mbps, for example, it'll go to 4.1
[23:26:22 CEST] <alexpigment> rather
[23:26:26 CEST] <alexpigment> *the encoder
[23:27:00 CEST] <Tatsh> is there a way ffmpeg can show the implicit arguments given due to preset?
[23:27:12 CEST] <BtbN> no, because it has no idea
[23:27:47 CEST] <Tatsh> alexpigment, given i have an ipad 4 in the house i think i must limit to 4.1
[23:29:47 CEST] <alexpigment> i think what might be better, imho, is to set a maxrate toward the top of the 4.1 (or 4.0) bitrate limit
[23:29:55 CEST] <alexpigment> and not specify a level at all
[23:30:10 CEST] <alexpigment> that way, you'll still end up with, say, level 3.2 for 720p60
[23:31:37 CEST] <alexpigment> e.g. -x264-params vbv-maxrate=25000:vbv-bufsize=25000
[23:32:28 CEST] <alexpigment> maybe there are downsides to that approach that i'm not aware of, but it would seem like it would cap you at 4.0 but automatically set the levels accordingly for different resolution inputs
[23:32:46 CEST] <alexpigment> (if the input resolution fluctuates)
[23:40:42 CEST] <Tatsh> at the very least i get 1.2x speed compared to 0.2x speed
[23:41:20 CEST] <alexpigment> oh right. nvenc. ignore the whole x264-params thing. i really should stop doing 2 things at once ;)
[23:41:28 CEST] <Tatsh> the naming is confusing, i don't know if this should be called 'passes' other than it can do a look-ahead
[23:41:38 CEST] <Tatsh> it can analyse up to 32 frames ahead of time
[23:42:05 CEST] <alexpigment> yeah, the whole ridiculous naming thing was discussed yesterday
[23:43:30 CEST] <alexpigment> i was original confused when i saw a preset called "2pass" that worked in 1pass mode :)
[23:43:34 CEST] <alexpigment> *originally
[00:00:00 CEST] --- Thu Apr  6 2017