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

[burek]

[04:00:06 CEST] <TheTallesT> Any ideas on why ffmpeg would return "Unknown encoder 'libcelt'" when compiled with --enable-libcelt and libcelt is listed in the output of 'ffmpeg -codecs'?
[04:02:28 CEST] <furq> libcelt is only for decoding iirc
[04:02:49 CEST] <furq> i don't have a build with it but if it doesn't have an E in ffmpeg -codecs then it's decode only
[04:03:01 CEST] <DHE> the letter codes in front of the codec indicate its types. 'D' for decode, 'E' for encode, etc
[04:04:12 CEST] <furq> also i assume you want celt for compat reasons, because it was obsoleted by opus a while back
[04:04:13 CEST] <TheTallesT> my bad.. thank you
[11:33:12 CEST] <linuxmaster> /bin/kill -HUP $MAINPID #does it work for avconv to change settings?
[11:46:10 CEST] <linuxmaster> how to use avconv as systemd service?
[13:41:14 CEST] <DHE> well, avconv is the old ffmpeg fork binary. (or maybe a compatibility name from people who used it). second ffmpeg isn't a background service
[14:50:02 CEST] <linuxmaster> DHE: really? -nostdin and we have background service
[15:39:21 CEST] <DHE> linuxmaster: well if you're doing that then you still need to give it the rest of the commandline. so really you're defining your own service
[15:39:25 CEST] <DHE> also, systemd. eww. :)
[15:47:19 CEST] <JEEB> DHE: as an init system it's much better than f.ex. sysv init or upstart
[15:48:17 CEST] <JEEB> speaking as someone who has gone through cargo cult sysv files, then upstart config files and finally systemd service files
[16:11:23 CEST] <BtbN> Anyone ever had issue with using the segment muxer to create a bunch of .ts files, and then when stitching them back together there is sometimes slight audio glitches on the boundaries of the segments?
[16:27:23 CEST] <bodqhrohro1> If in geq red_expr I sum values from several pixels, do they get trunkated by the maximum value or overflown?
[16:30:54 CEST] <DHE> JEEB: while I disagree, this is not the place to be talking about it.
[16:31:40 CEST] <DHE> I've found ffmpeg isn't that great of a continuously running daemon because a continuous video feed is never reliable enough to make it happy.
[16:55:32 CEST] <linuxmaster> NEVER. Never use symbol links in your systemd units!
[17:00:46 CEST] <bodqhrohro1> linuxmaster: what happened?
[17:12:14 CEST] <bodqhrohro1> And what scale does red_expr have? Is it 0..255, or 0..1?
[17:14:01 CEST] <JEEB> DHE: dunno, I've seen ffmpeg.c happily churn for days from a live input which is why a lot of PoCs are too simple to do with it and people think they can get away with ffmpeg.c by itself :D
[17:17:09 CEST] <hrvoje> From my experience, ffmpeg works very reliably for days and weeks, even in nvidia (nvenc) configuration
[17:30:21 CEST] <rasten33> i got 101 problems but systemd aint one
[17:35:07 CEST] <Cracki> didn't you mean 109
[19:03:41 CEST] <alcane> I have a 3.3GB mp4 that won't open in vlc or mpv. Ideas on how I should go about cutting this down? How can I find how long the video is?
[19:06:13 CEST] <JEEB> try ffprobe'ing it? the track duration should be a general field in ISOBMFF (aka "mp4")
[19:06:30 CEST] <JEEB> or if that doesn't work, `boxdumper --box file.mp4` and pipe into less or something
[19:06:44 CEST] <JEEB> which will show you all the boxes in the file
[19:06:53 CEST] <JEEB> (boxdumper is part of l-smash)
[19:10:55 CEST] <alcane> JEEB: moov atom not found =/
[19:11:31 CEST] <JEEB> sounds like you're missing the initialization data
[19:11:46 CEST] <JEEB> if this is a web rip, make sure you get the initialization segment first
[19:11:52 CEST] <JEEB> and prepend it to the whole thing
[19:15:44 CEST] <alcane> no, it's a video someone recorded on their laptop
[19:15:53 CEST] <alcane> mplayer cli revealed it's a rawdv file
[19:16:32 CEST] <JEEB> I'd be surprised, since usually libavformat can probe the container
[19:16:46 CEST] <JEEB> even if the extension looks like something else
[19:17:49 CEST] <alcane> so.... transcode it? I'm not familiar with video, lol
[19:17:50 CEST] <JEEB> not suer what exactly "rawdv" means but if it's "dv" then `ffmpeg -f dv -i file` might output something (will probably work with ffprobe as well)
[19:20:48 CEST] <alcane> JEEB: https://pastebin.com/mAGVGYv2
[19:22:22 CEST] <JEEB> that's probably not raw DV
[19:22:31 CEST] <JEEB> if it can find a major brand etc
[19:22:46 CEST] <JEEB> most likely the file is just cut in the middle before writing was finished?
[19:23:34 CEST] <alcane> i wouldn't doubt it. I'm pretty sure he just hit record and let it fill ram/cache until his computer crashed, lol
[19:23:37 CEST] <JEEB> if l-smash's boxdumper can output sensible stuff then I'd say it's an mp4 file but never finished
[19:24:27 CEST] <JEEB> alcane: there's some apps for possibly fixing such things if you have a working example, but in general it's not a good idea to do non-fragmented mp4 if you are going to have a thing crash or just get killed before it writes all the data
[19:25:34 CEST] <JEEB> basically something with the exact same parameters/resolution/etc from the same camera/capture software
[19:25:49 CEST] <alcane> that's why I don't record things with a computer. They make camera's for such things. ;) I just wanna get this guy his video file watchable in some form.
[19:26:00 CEST] <JEEB> even cameras can stop before they finished their mp4
[19:26:09 CEST] <JEEB> we've had plenty of people come here with camera files
[19:26:15 CEST] <JEEB> with a similar issue
[19:26:34 CEST] <alcane> so this boxdumper is it's own program?
[19:26:44 CEST] <DHE> more like using a format or settings that produce a crash-tolerant file
[19:26:57 CEST] <alcane> so it's a cli?
[19:32:32 CEST] <alcane> oh well, it's the other dude's problem. I tried. Thanks!
[19:33:59 CEST] <linuxmaster> bodqhrohro1: they do not work in units
[19:34:34 CEST] <linuxmaster> bodqhrohro1: /usr/bin/avconv is a symbol link to /usr/bin/ffmpeg
[19:34:34 CEST] <bodqhrohro1> linuxmaster: just like in AppArmor, huh
[19:35:15 CEST] <linuxmaster> bodqhrohro1: well... When I use absolute links - it works
[19:35:33 CEST] <linuxmaster> feel myself stupid
[20:35:02 CEST] <bodqhrohro1> Here's an MWE:
[20:35:03 CEST] <bodqhrohro1> [0:v] geq=cr=st(mod(X\,8)+1\, cr(X\,Y))\; ld(mod(X+1\,8)+1): cb=cb(X\,Y):lum=lum(X\,Y) [out]
[20:35:03 CEST] <bodqhrohro1> This filter works totally not as I expect it to. Instead of halo, there are strange vertically teared flakes https://pic4a.ru/87/g0i.jpg What order are pixels processed in?
[20:36:58 CEST] <bodqhrohro1> Oh, I think I got it. cb/cr resolution is twice less than luminance one
[20:43:30 CEST] <ayum> Hi, I have a question about the hwdownload and hwupload filter, if I use the command like this  -hwaccel cuvid -c:v mpeg2_cuvid -i URL filter_complex "hwdownload,format=nv12,split=2[out0][out1];[out0]hwupload;[out1]hwupload" -c:v h264_nvenc ..., It's correct or not? seems it will increase huge memory copy overhead
[22:12:23 CEST] <Robert34> Hi, I use avcodec_decode_audio4 on raw aac frames. The resulting AVFrame struct always has nb_samples == 1024. This is wrong, since only the average is 1024 samples/frame, any ideas?
[22:15:26 CEST] <atomnuker> no, aac always has 1024 samples per frame
[22:20:25 CEST] <Robert34> Then how is it possible that the 'stts' atom doesnt only contain 1024 samples/frame?
[00:00:00 CEST] --- Mon Jul 30 2018