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

[burek]

[00:00:09 CEST] <JEEB> is this with latest FFmpeg?
[00:00:22 CEST] <JEEB> and what version of libvpx?
[00:00:42 CEST] <JEEB> and you get to that error with
[00:00:43 CEST] <JEEB> if (ctx->crf < enccfg.rc_min_quantizer || ctx->crf > enccfg.rc_max_quantizer)
[00:00:59 CEST] <ovi> true it makes no sens .. [min-max] should be [50-5000] not [5000-50]
[00:01:18 CEST] <JEEB> so if your CRF is smaller than minimal quantizer OR CRF is larger than maximum quantizer
[00:01:46 CEST] <jkqxz> Have you somehow set qmin to 5000?
[00:02:15 CEST] <ovi> i compiled ffmpeg-4.0 from sources
[00:02:36 CEST] <ovi> libvpx 1.7.0
[00:02:44 CEST] <jkqxz> Because I can't see any other way to get a crazy value there.
[00:02:56 CEST] <JEEB> can you post your full command line with full terminal output in a pastebin-like?
[00:02:59 CEST] <JEEB> and link it here
[01:18:28 CEST] <oerg866> alright here's the bug
[01:18:30 CEST] <oerg866> command line:
[01:18:33 CEST] <oerg866> ffmpeg -i a.vob -i a.wav -vcodec copy -an -shortest C:\output\tmp.vob
[01:18:42 CEST] <oerg866> er whooops
[01:18:44 CEST] <oerg866> wrong command
[01:18:50 CEST] <oerg866> ffmpeg -i a.vob -i a.wav -vcodec copy -acodec pcm_s16be -ar 48000 -shortest tmp.vob
[01:19:03 CEST] <oerg866> audio duration=213.172122
[01:19:09 CEST] <oerg866> video duration=213.040000
[01:22:16 CEST] <oerg866> I might be mistaken but I'm pretty sure they're supposed to be the same after muxinbg
[01:51:04 CEST] <Nkekev> hello
[01:51:47 CEST] <Nkekev> I have a little question if someone can help me with my output?
[01:53:12 CEST] <Nkekev> I want to encode some video to have the closest format as another one i have to be compatible with a game
[01:53:32 CEST] <Nkekev> So thats i get with ffmpeg -i on my source video
[01:53:54 CEST] <Nkekev> https://pastebin.com/zFYgndYd
[01:54:07 CEST] <Nkekev> what settings should i use to get the same ?
[02:36:35 CEST] <Nkekev> zz
[02:45:01 CEST] <Exagone313> Hi, I'm trying to compile git version of ffmpeg with --enable-libaom and git version of aom installed, and I get "ERROR: aom >= 0.1.0 not found using pkg-config", although `pkg-config --modversion aom` returns 0.1.0
[02:48:01 CEST] <Nkekev> chat is dead
[02:48:39 CEST] <Exagone313> hmm weird /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../lib/libaom.so: undefined reference to `pthread_once'
[02:48:46 CEST] <Exagone313> in config.log
[02:49:30 CEST] <Exagone313> -pthread is missing
[03:14:07 CEST] <Exagone313> ok, it's a bug from aom, -lpthread is not correctly used in their pkg-build file
[03:14:18 CEST] <Exagone313> pkg-config*
[04:09:51 CEST] <darkdrgn2k> hi all
[04:10:11 CEST] <darkdrgn2k> i keep betting "value too large for defined data type" when i try to process a ATSC DVB stream and it exits
[04:10:17 CEST] <darkdrgn2k> i alreayd did the cat test and that seem to work
[07:37:44 CEST] <oerg866> What's the recommended way to convert NTSC 29.97 progressive to PAL 25 interlaced?
[07:49:18 CEST] <kepstin> oerg866: the correct way is to not do it at all, since you often don't have to with modern tvs :/
[07:49:38 CEST] <oerg866> yeah but the end result kinda needs to be in PAL interlaced format for some hobby purposes ;)
[07:50:30 CEST] <kepstin> there's no good options. you can drop frames or fields and get judder, blend stuff, do motion-compensated framerate conversion with varying results, :/
[07:52:12 CEST] <oerg866> i found a "decent" way to cvonvert ntsc interlaced to pal interlaced
[07:52:24 CEST] <oerg866> ffmpeg -i gf.vob -vf yadif=1,scale=720x576,setdar=4:3,minterpolate='fps=50:mi_mode=blend',tinterlace=5 -vcodec mpeg2video -acodec pcm_s16be -b:v 15000k -flags +ilme+ildct TEST.mpeg
[07:52:38 CEST] <oerg866> it's not perfect but good enough for my purposes
[07:52:51 CEST] <oerg866> the material is going to be recorded to VHS so the quality difference matters very little :P
[07:52:58 CEST] <furq> that seems way overcomplicated
[07:53:13 CEST] <oerg866> well I'd love to hear a less complicated way
[07:53:19 CEST] <furq> i'm pretty sure you could just use -vf scale=720:576:interl=1,fps=25
[07:53:22 CEST] Action: kepstin notes that 720x576 isn't 4:3 dar, although it's close.
[07:53:38 CEST] <furq> you might need to setsar as well, i don't really know
[07:53:40 CEST] <kepstin> furq: that'll give you some pretty nasty judder, i'd think.
[07:53:45 CEST] <oerg866> no, setdar is good enough
[07:53:55 CEST] <oerg866> furq that will not work
[07:54:01 CEST] <oerg866> it will scale to 720x576 with all interlace artifacts
[07:54:23 CEST] <kepstin> oerg866: that does an interlaced scale (scale each field separately)
[07:54:35 CEST] <oerg866> does it?
[07:54:36 CEST] <oerg866> let me try
[07:54:52 CEST] <furq> yeah scale=interl is interlacing-aware
[07:55:18 CEST] <furq> that'll basically just drop every sixth frame so it's still going to be a bit juddery
[07:55:19 CEST] <kepstin> but yeah, setsar and setdar conflict with eachother; using one after the other means the second will overwrite the results of the first.
[07:55:39 CEST] <furq> but it should be ok-looking and way faster than using minterpolate
[07:55:41 CEST] <oerg866> it does look quite jerky
[07:55:56 CEST] <oerg866> minterpolate is not slow at all when using blend mode
[07:55:59 CEST] <oerg866> which I'm using
[07:56:02 CEST] <kepstin> setsar calculates a new dar from the provided sar and the frame size
[07:56:06 CEST] <oerg866> but yeah your methid is way too jerky for my taste
[07:56:09 CEST] <kepstin> setdar calculates a new sar from the provided sar and the frame size
[07:56:17 CEST] <kepstin> setdar calculates a new sar from the provided dar and the frame size*
[07:56:40 CEST] <oerg866> it makes my content display at the aspect ratio I want
[07:57:20 CEST] <oerg866> I've done VHS digitzation with intent to upload to youtube at 720p50 by converting it to 720x720 and giving it setdar=4:3
[07:57:32 CEST] <furq> fwiw you can use yadif on field-based content
[07:57:32 CEST] <oerg866> gives you more quality per bitrate
[07:57:39 CEST] <furq> so that method should still work on 29.97p
[07:57:43 CEST] <furq> er, frame-based
[07:57:51 CEST] <furq> idk if it'll give good results
[07:58:03 CEST] <furq> i can't immediately think of anything else that isn't even hackier
[07:58:44 CEST] <kepstin> old analog video standards are weird, for pal 4:3 content you probably want setsar=16/15
[07:59:06 CEST] <kepstin> the 720-sample per line video include stuff past the edges of the picture on either side
[07:59:42 CEST] <kepstin> that said, depending how you're outputting this for the tape recording, it's probably not that important.
[08:00:45 CEST] <kepstin> hmm, i'm not even sure I got the right value there. I don't touch pal stuff much :)
[08:00:49 CEST] <furq> yeah
[08:00:59 CEST] <furq> it's 16:15 for 720*576 and 12:11 for 704*576
[08:01:07 CEST] <furq> for fullscreen obviously
[08:01:09 CEST] <kepstin> 12:11 looks right, yeah
[08:03:01 CEST] <oerg866> this is seriously messing with my head and I haven't slept yet
[08:03:07 CEST] <oerg866> i'll mess with this later, thanks for the pointers
[08:09:27 CEST] <furq> i'm sort of wondering how studios dealt with this now
[08:10:00 CEST] <furq> at least ntsc to pal interlaced, which definitely happened a lot
[08:10:03 CEST] <kepstin> tv studios or movie studios? :)
[08:10:06 CEST] <furq> tv studios
[08:10:09 CEST] <furq> i know how movie studios did it
[08:10:49 CEST] <kepstin> a lot of the pal->ntsc conversions I've seen have nasty blended fields and can't be cleanly deinterlaced.
[08:11:09 CEST] <kepstin> (you get some ghosting on the intermediate frames)
[08:11:27 CEST] <furq> actually i guess most of the american sitcoms i'm thinking of were shot on film
[08:11:52 CEST] <furq> there probably wasn't actually that much that was shot on video that made it over here
[08:11:59 CEST] <furq> certainly not much i'd have been watching
[08:13:26 CEST] <kepstin> I should try to find some recent north american releases of some bbc shows or something, check how they did that.
[08:14:03 CEST] <furq> well not too recent or it'll be progressive
[08:15:03 CEST] <kepstin> hm, still could be interesting to see how they handled the 25p to 24p (or 30p?) conversion. But I might have to go look for some dvds instead to find interlaced stuff :)
[08:16:19 CEST] <furq> i think i actually have a bootleg region 1 dvd of a bbc show shot on video somewhere
[08:16:22 CEST] <furq> i should dig that out
[08:16:38 CEST] <furq> bootleg as in a copy of an official release
[09:06:35 CEST] <oerg866> furq / kepstin well the thing is
[09:06:55 CEST] <oerg866> a lot of music videos of stuff that wasn't really popular in europe
[09:07:04 CEST] <oerg866> or american bands to begin with
[09:07:23 CEST] <oerg866> you know you can watch VH1 classic which is an USA NTSC station here in Germany's major cable networks in PAL
[09:07:25 CEST] <oerg866> i just wonder how they do it
[09:07:43 CEST] <oerg866> i also have some recordings of 80s music shows from german television
[09:07:48 CEST] <oerg866> that showed some american videos
[09:07:53 CEST] <oerg866> even back then the technology was there! but how???
[09:25:28 CEST] <furq> oerg866: i did find a bunch of avisynth scripts that supposedly do this
[09:25:42 CEST] <furq> there's at least one on the wiki and a bunch in forums
[09:25:48 CEST] <furq> you could probably port those to lavfi pretty easily
[09:27:17 CEST] <furq> they're pretty much doing deinterlace, resize, change fps, separate fields, select first and fourth field of every four, weave
[09:27:30 CEST] <furq> but using convertfps which interpolates frames together
[09:30:37 CEST] <AlecTaylor> hi
[09:31:08 CEST] <AlecTaylor> Speeding up a video using ffmpeg, but the result has no audio track, how to fix? - `ffmpeg -i myvideo.mov -vf "setpts=0.78*PTS" -an /tmp/speedy.mov`
[09:31:57 CEST] Action: AlecTaylor notes video is h264 and audio is 2channel aac
[09:32:49 CEST] <furq> AlecTaylor: -an removes the audio track
[09:33:44 CEST] <furq> also you probably want to add -af "atempo=1/0.78"
[09:33:48 CEST] <furq> otherwise the audio will be out of sync
[09:37:04 CEST] <AlecTaylor> Perfect, thanks furq
[09:38:53 CEST] <durandal_1707> furq: all those filter are already in lavfi
[09:38:59 CEST] <furq> yeah, i said that
[09:39:10 CEST] <furq> i meant he could port the script, not the filters
[09:40:04 CEST] <oerg866> interestingly enough
[09:40:40 CEST] <oerg866> furq: adobe premiere's way of doing things looks a bit like how I saw it on the old TV recordings of NTSC material on PAL channels
[09:40:45 CEST] <oerg866> it looks quite nice actually
[09:41:24 CEST] <oerg866> it's probably doing it in some industry standard way
[09:42:27 CEST] <oerg866> now if only the process of doing that on adobe premiere was scriptable :-)
[09:42:32 CEST] <durandal_1707> oerg866: what you want to do? I missed previous log
[09:42:41 CEST] <furq> durandal_1707: ntsc interlaced to pal interlaced
[09:43:09 CEST] <oerg866> I've got some NTSC 720x480 29.97 interlaced music videos i'd like to convert to PAL 720x576 25.00 interlaced
[09:43:10 CEST] <furq> or uh
[09:43:14 CEST] <furq> ntsc progressive wasn't it
[09:43:22 CEST] <oerg866> that was a specific subset of my question
[09:43:26 CEST] <furq> fair enough
[09:43:33 CEST] <oerg866> some of the videos are progressive to begin with and thus fairly straightforward
[09:43:34 CEST] <furq> i don't suppose it makes too much difference
[09:43:49 CEST] <oerg866> since the framerate is higher it makes sense to interpolate to 50 and then interlace it
[09:44:00 CEST] <oerg866> gets a higher perceived framerate I suppose
[09:44:01 CEST] <furq> if it's not telecined then it's probably equally awkward either way
[09:44:16 CEST] <oerg866> Well the problem with telecined is the following
[09:44:25 CEST] <oerg866> yes most material is shot on film in 23.976 or whatever
[09:44:38 CEST] <oerg866> but the cuts and fades are NOT cleanly done on original frames
[09:44:51 CEST] <oerg866> like you'd have fades that are inbetween two "film frames"
[09:44:54 CEST] <oerg866> or cuts
[09:45:07 CEST] <oerg866> so you'd have one frame of NASTY interlace artifacts in your inverse telecined videos
[09:45:17 CEST] <furq> yeah that's just a general ivtc issue though
[09:45:28 CEST] <oerg866> still nasty to look at
[09:45:30 CEST] <furq> sure
[09:45:36 CEST] <oerg866> and the next issue is for PAL playback you'd usually just speed the ~24 to 25
[09:45:54 CEST] <oerg866> since this is music the pitch change is rather annoying and noticable and I don't like pitch correctors, they sound so mechanical
[09:46:11 CEST] <oerg866> (and the speed being off knowing how the song sounds like in the original still annoys me)
[09:46:25 CEST] <furq> i take it this isn't telecined anyway
[09:46:36 CEST] <oerg866> a lot of it actually is
[09:46:42 CEST] <oerg866> but as I said, the cuts :-/
[09:46:52 CEST] <furq> true
[09:47:04 CEST] <furq> there is some ridiculous pulldown method for film to pal that avoids the speedup
[09:47:15 CEST] <furq> but if your issue is with the ivtc bit then that doesn't help
[09:47:15 CEST] <oerg866> yeah the euro pulldown
[09:47:20 CEST] <oerg866> 12 progressive, 13 interlaced frames
[09:47:21 CEST] <oerg866> :D
[09:48:01 CEST] <furq> good old 2:2:2:2:2:2:2:2:2:2:2:3 pulldown
[09:48:09 CEST] <oerg866> XD
[09:48:41 CEST] <oerg866> i dunno did the guy who invented that just think "oh I know, I'm going to fuck with peoples' heads real hard 8)"
[09:49:06 CEST] <furq> it's specifically to avoid the pitch change i think
[09:49:13 CEST] <furq> there's no other good reason for it
[09:49:41 CEST] <oerg866> yeah I know the motive makes good sense
[09:50:11 CEST] <oerg866> but it didnt hold up too well since most film -> PAL stuff is just sped up to 25 :P
[09:51:05 CEST] <oerg866> OH yeah another issue with inverse telecine
[09:51:09 CEST] <oerg866> with mpeg2 stuff
[09:51:29 CEST] <oerg866> you're going to see interlace artifacts where the compression artifacts were in the individual fields :-D
[09:52:07 CEST] <furq> i think it's fairly common to use a proper deinterlacer in an ivtc pipeline nowadays
[09:53:01 CEST] <oerg866> probably
[09:53:19 CEST] <furq> i've definitely seen people using qtgmc after decimating
[09:53:26 CEST] <furq> but that's not going to be quick
[09:53:35 CEST] <oerg866> I really want to see what qtgmc looks like
[09:53:44 CEST] <oerg866> unfortunately I lack the will power to get into avisynth
[09:53:53 CEST] <furq> you can use it with vapoursynth these days
[09:54:02 CEST] <oerg866> I have no idea what that is :-(
[09:54:13 CEST] <furq> it's cross-platform avisynth with multithreading that isn't fucked
[09:54:27 CEST] <furq> it's not really much easier to set up or script though
[09:54:34 CEST] <furq> especially on windows
[09:54:45 CEST] <oerg866> I don't know man, I was pretty content with yadif so far
[09:54:56 CEST] <oerg866> I'd love to use it in my VHS digitzation projects if it's actually a noticable improvement
[09:55:08 CEST] <furq> well if you're using it after decimating then you'd be using it in progressive mode
[09:55:23 CEST] <oerg866> yeah no I meant like in general
[09:55:29 CEST] <furq> which just tries to clean up interlacing artifacts in progressive video
[09:55:36 CEST] <furq> it's an absolute godsend lol
[09:55:46 CEST] <oerg866> aaaaah now that makes more sense to my head
[09:55:50 CEST] <oerg866> yeah that's probably a good idea actually
[09:56:02 CEST] <oerg866> jeez why didn't I think of that before ._.
[09:56:11 CEST] <furq> there's not really any other filter i know of that does that
[09:56:24 CEST] <furq> that's pretty much the only thing i use vs for
[09:56:38 CEST] <furq> also yeah qtgmc is slower than shit
[09:56:52 CEST] <oerg866> I've got about 50 VHS tapes full of music shows from 1984 until 1989... I need to figure out a nice pipeline for that
[09:57:09 CEST] <oerg866> digitizing those
[09:58:04 CEST] <oerg866> most definitely gonna have to use avisynth or that replacement you just mentioned for that
[09:58:11 CEST] <oerg866> need to fix chroma shifts etc
[09:58:24 CEST] <furq> i would definitely use vs over avs if you're planning on looking at qtgmc
[09:58:42 CEST] <furq> i tried avisynthmt and it just kept crashing on me like 5+ hours into an encode
[09:58:53 CEST] <oerg866> yeah i've heard it was an absolute hackjob
[09:59:04 CEST] <furq> vs is a little bit slower but it's been totally stable for me
[09:59:11 CEST] <furq> and most good stuff is ported
[09:59:58 CEST] <furq> it still has the same fundamental problem as avs though, which is that package management is "trawl through doom9 forums"
[10:00:48 CEST] <oerg866> :D
[10:00:48 CEST] <durandal_1707> furq: what's so special about qtgmc?
[10:01:05 CEST] <furq> the progressive mode is the most special thing
[10:01:17 CEST] <furq> as an actual deinterlacer it's just good quality
[10:01:23 CEST] <oerg866> ahhhhhhh I remember now why I gave up on the digitization last time
[10:01:26 CEST] <oerg866> https://i.snag.gy/a2gLIE.jpg
[10:01:31 CEST] <oerg866> I couldn'T figure out how to denoise this episode
[10:01:39 CEST] <oerg866> which was recorded off a different station off antenna
[10:01:39 CEST] <furq> but it does a really good job of repairing interlacing artifacts in progressive frames
[10:01:49 CEST] <furq> which i have a lot of because bbc dvds are terribly produced
[10:01:58 CEST] <oerg866> all denoisers work horizontally and vertically, but analog video is line based . . .
[10:03:19 CEST] <furq> but yeah i'm not going to pretend i know what qtgmc does that lavfi nnedi doesn't
[10:03:33 CEST] <furq> i just know it looks better than yadif/bwdif on sd mpeg2
[10:03:36 CEST] <furq> and i have a lot of that
[10:04:27 CEST] <oerg866> would you say it looks better than yadif if the source material hasnt been lossily compressed?
[10:04:35 CEST] <oerg866> i.e. capture card -> lagarith -> deinterlacer
[10:04:39 CEST] <furq> probably not
[10:04:56 CEST] <furq> i don't really know how fields are stored on vhs
[10:05:14 CEST] <oerg866> well pretty much the same as on any other interlaced source
[10:05:18 CEST] <furq> if you get bleeding between fields then maybe
[10:05:22 CEST] <oerg866> bottom field first, PAL timing
[10:05:34 CEST] <oerg866> nah, the fields are stored cleanly after one another
[10:05:46 CEST] <furq> yeah it probably won't make much difference then
[10:06:00 CEST] <furq> nnedi is a better upscaler than whatever yadif uses, but it's not going to be a big enough difference to be worth how slow it is
[10:06:59 CEST] <durandal_1707> nnedi is for anime fans
[10:07:10 CEST] <oerg866> that's quite specific :D
[10:07:47 CEST] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_nnedi.c#L3
[10:07:48 CEST] <furq> wait a minute...
[10:11:28 CEST] <oerg866> hm?
[10:11:34 CEST] <durandal_1707> you need motion compesated/adaptive bob filter
[10:26:49 CEST] <oerg866> ugh this whole chain disgusts me
[10:26:58 CEST] <oerg866> >British band, PAL material
[10:27:09 CEST] <oerg866> >only DVD releases are NTSC
[10:27:23 CEST] <oerg866> >i convert it back to PAL for my own purposes
[10:27:30 CEST] <oerg866> the world has gone crazy!
[13:11:46 CEST] <GamleGaz> Hey, do I need to decode audio before resampling it, or can svresample handle encoded audio?
[13:59:41 CEST] <Freneticks> I trying to -c copy a stream and my writing speed is 0.1x any idea where it came from, slow network ?
[14:16:03 CEST] <kerio> oerg866: the worst part is that you're converting to PAL for some reason
[15:37:55 CEST] <Zgrokl> hi any help on my stream copy problem ?
[15:55:03 CEST] <relaxed> Zgrokl: what is the problem?
[15:55:25 CEST] <Zgrokl> i ffmpeg -i (youtube-dl -g url) -c copy stream.ts
[15:55:36 CEST] <Zgrokl> but writespeed is 0.123 relaxed
[15:56:13 CEST] <Zgrokl> I just want to copy with normal speed without reencoding
[16:21:47 CEST] <relaxed> pastebin.com ffmpeg's output
[16:42:17 CEST] <romano2k_> hi there! i'm trying to convert a burst of images into a x264 video, but somehow i get a very high bitrate, i don't understand why
[16:42:34 CEST] <romano2k_> ffmpeg -framerate 10 -start_number 0 -pattern_type glob -i '*.jpg' -filter:v "scale=3840:2880,crop=3840:2160,format=yuv420p" -codec:v libx264 -crf 20 output.mp4
[16:42:39 CEST] <romano2k_> any idea what's wrong?
[16:44:30 CEST] <romano2k_> here is the result: https://pastebin.com/ycCifjSf
[16:48:57 CEST] <nille02> Hello everyone, i got a small problem with ffmpeg while configure.
[16:48:58 CEST] <nille02> ERROR: x265 not found using pkg-config
[16:49:19 CEST] <nille02> it is there and this is the config.log https://www.dropbox.com/s/5z1te12vtlqoghz/config.log?dl=0
[16:52:42 CEST] <c_14> are you cross compiling?
[16:56:05 CEST] <nille02> yes
[16:56:05 CEST] <c_14> nille02: what version of x265 is that?
[16:56:21 CEST] <c_14> git head?
[16:56:25 CEST] <nille02> git head
[16:57:23 CEST] <nille02> hg head
[16:57:26 CEST] <c_14> well, mercurial but w/e
[16:58:04 CEST] <c_14> Your x265.h lists bool bEnableavx512 but the current hg source has int bEnableavx512
[16:58:07 CEST] <nille02> and about compiling i use a mysy2 enviroment
[16:58:15 CEST] <c_14> and I can't find a version in which it's bool
[16:58:41 CEST] <c_14> wait
[16:58:57 CEST] <c_14> ok, looks like it was the latest commit
[16:59:13 CEST] <c_14> anyways, they're using bool without including stdbool.h
[16:59:17 CEST] <c_14> so it's a bug on their end
[16:59:25 CEST] <c_14> use an older x265 version
[16:59:39 CEST] <nille02> ok i try it. thank you
[17:02:51 CEST] <c_14> It works for the x265 internal stuff because that's C++ but when you include the file in C bool isn't a recognized type without stdbool.h
[17:33:12 CEST] <nille02> c_14 thank you, its build again. i switched to the default branch
[17:47:57 CEST] <Nethe> Hi :) I'm facing problems when creating multicast with multiple streams from one source (live source). The issue is that the encoding is slower than realtime. That is big issue for me as I'm processing live feed. The exact command and it's output you can find here: https://pastebin.blesmrt.net/p4bw0pmqm/vpacnu
[17:54:30 CEST] <oerg866> <kerio> oerg866: the worst part is that you're converting to PAL for some reason
[17:54:37 CEST] <oerg866> I live in a PAL region :)
[17:54:40 CEST] <kerio> it's 2018
[17:55:11 CEST] <oerg866> oh really, einstein
[18:57:49 CEST] <wallnut> hello! I want to re-encode a video from h264 to h265 but the colors in the result are always washed out, the blacks are almost grays. ffprobe says this about the source: "Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc), 1920x1080, 5456 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)", is this a problem with color range (since it's yuv*J*420p)? what could I try in order to keep the color quality? thanks.
[19:01:12 CEST] <JEEB> wallnut: yea it sounds like something in the chain is forgetting about the PC flag
[19:01:20 CEST] <JEEB> (see the (pc) after the pix_fmt)
[19:05:21 CEST] <wallnut> yes, the output gets a "tv" instead of "pc" there, any pointer on what to try?
[19:07:35 CEST] <durandal_1707> wallnut: are you doing filtering by any chance?
[19:10:01 CEST] <wallnut> no, i'm just doing this: ffmpeg -i "input.mp4" -c:v libx265 -c:a copy "output.mp4"
[19:10:48 CEST] <wallnut> ffmpeg warns "deprecated pixel format used, make sure you did set range correctly" and then the output is "Video: hevc (Main) (hev1 / 0x31766568), yuv420p(tv, progressive), 1920x1080, 1358 kb/s, 25 fps, 25 tbr, 12800 tbn, 25 tbc (default)"
[19:11:17 CEST] <wallnut> i tried fiddling with -color_range and -pix_fmt but nothing seemed to change (for the better or for the worse)
[19:14:00 CEST] <JEEB> wonder if that thing is plugged anywhere in the x265 wrapper
[19:14:37 CEST] <wallnut> i also tried -x265-params range=full, is that what you're talking about?
[19:15:11 CEST] <JEEB> if libx265 takes it like that, then that should pass things into libx265 as-is
[19:15:31 CEST] <JEEB> x265-params just passes key=value pairs to libx265 itself
[19:16:40 CEST] <jkqxz> You could fix it up after the encode by adding -bsf:v hevc_metadata=video_full_range_flag=1
[19:17:14 CEST] <JEEB> ok, seems like libx265 wrapper has nothing related to range
[19:17:36 CEST] <durandal_1707> that is bad
[19:18:07 CEST] <durandal_1707> does it support different ranges at all?
[19:18:53 CEST] <JEEB> I think libx265 itself does, the wrapper only takes in non-J pix_fmts and has no "range" string in it
[19:19:26 CEST] <durandal_1707> ugh, that means that it will be probably converted to limited range
[19:19:44 CEST] <JEEB> yes, which thankfully now is borked so mos tlikely the only thing changing is the pix_fmt and range flag :D
[19:19:56 CEST] <JEEB> which is why the content doesn't look right
[19:21:00 CEST] <durandal_1707> code is stupid, yuvj formats when converted to yuv are converted to limited
[19:21:30 CEST] <durandal_1707> i wanted to fix this crap, but michaelni did not helped at all
[19:21:37 CEST] <atomnuker> you fixed it damn it!
[19:21:52 CEST] <atomnuker> you just didn't resend your patchset and left it rotting
[19:25:15 CEST] <wallnut> jkqxz: i just tried that, no difference, did i do it right? just add -bsf:v ... with the other params
[19:27:35 CEST] <jkqxz> At the end, yeah.  It won't work if some other conversion is happening in the middle, though, and it sounds like that's the case.
[19:29:03 CEST] <wallnut> aw :(
[19:29:34 CEST] <jkqxz> (It's just marking the metadata on the stream to say it's full range, if something else has messed that up then it doesn't help.)
[19:29:55 CEST] <JEEB> yea, you use it with -c copy after the encode
[19:30:00 CEST] <JEEB> not during the encode
[19:31:02 CEST] <wallnut> yup, i tried that too
[19:31:33 CEST] <wallnut> is there anything i can do to help fix it?
[19:32:07 CEST] <JEEB> I would double-check the libx265 API key=value for full (pc) range
[19:32:13 CEST] <JEEB> and then just use x265-params
[19:32:54 CEST] <jkqxz> Seems like it should be 'range=full'.
[19:33:05 CEST] <jkqxz> From the source.  Dunno if that actually works.
[19:33:55 CEST] <JEEB> and then ffprobe -v verbose FILE'ing the generated file probably would then show it if the flag got applied
[19:34:00 CEST] <wallnut> i've seen mentions of it working: https://stackoverflow.com/a/47901085
[19:34:12 CEST] <wallnut> okay, let me try
[19:42:58 CEST] <wallnut> 'range=full' seems to be at least doing something: ffprobe of the output changes from "yuv420p(tv, progressive)" to "yuvj420p(pc, progressive)"
[19:43:13 CEST] <JEEB> yup
[19:43:17 CEST] <JEEB> so it is flagging the output stream
[19:43:26 CEST] <JEEB> now you just need to use a player that handles full range correctly
[19:43:28 CEST] <JEEB> most do not
[19:43:31 CEST] <JEEB> unfortunately
[19:43:39 CEST] <JEEB> try out mpv for example
[19:44:09 CEST] <wallnut> hmm, would ffplay be ok?
[19:44:35 CEST] <JEEB> not sure :D
[19:44:41 CEST] <JEEB> it's a proof of concept thing
[19:48:14 CEST] <wallnut> okay, i tried with mpv, colors still washed out in output
[19:48:31 CEST] <JEEB> :< hopefully that was with the opengl-based rendering
[19:48:43 CEST] <JEEB> but yea, that means something is playing with the values too
[19:48:46 CEST] <wallnut> well, i don't know if it's relevant but i'm on windows
[19:48:50 CEST] <JEEB> is the input RGB or...?
[19:49:34 CEST] <wallnut> i... don't really know, it's a video from a camera that somebody sometime converted with ffmpeg probably
[19:50:29 CEST] <JEEB> what does ffprobe -v verbose say about the input?
[19:51:26 CEST] <wallnut> Video: h264 (High), 1 reference frame (avc1 / 0x31637661), yuvj420p(pc, left), 1920x1080 (1920x1088), 5456 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
[19:51:48 CEST] <JEEB> ok, so no additional colorimetry info
[19:52:20 CEST] <wallnut> i can cut a couple of seconds and share the file if you want, it has no copyright or anything
[19:57:53 CEST] <wallnut> i was using 4.0, i just tried with a build from a couple days ago, same result
[20:06:18 CEST] <wallnut> should i open a bug?
[20:44:13 CEST] <durandal_1707> wallnut: if you can
[21:00:31 CEST] <wallnut> sure, i will
[21:08:09 CEST] <oerg866> is there a way in ffprobe to only output a certain information
[21:08:12 CEST] <oerg866> i.e. stream duration?
[21:12:54 CEST] <JEEB> I would recommend using the json output and using -show_streams or so
[21:13:05 CEST] <JEEB> that way you can parse things relatively easily
[21:13:09 CEST] <kepstin> oerg866: yes, see the -show_entries option
[21:13:14 CEST] <JEEB> with any modern language
[21:13:19 CEST] <JEEB> and yes, short_entries limiting works too
[21:14:06 CEST] <oerg866> i don't intend to do fancy processing; I just want the video length so i can make the audio that exact length
[21:14:20 CEST] <oerg866> because -shortest is buggy and just doesn't do what it says ._.
[21:15:38 CEST] <kerio> -of csv=p=0
[21:16:56 CEST] <wallnut> um, if i encode directly to h265 without any special parameters, mpv *does* show correctly the colors
[21:17:11 CEST] <wallnut> does this mean it's a player problem and not ffmpeg's?
[21:18:17 CEST] <durandal_1707> no, post full uncut ffmpeg command
[21:18:59 CEST] <oerg866> dayum kerio you're a saint
[21:19:00 CEST] <oerg866> thanks
[21:19:13 CEST] <wallnut> ffmpeg -i input.mp4 -c:v libx265 -an output.mp4
[21:19:28 CEST] <durandal_1707> command that does not work?
[21:21:09 CEST] <wallnut> ffmpeg -i input.mp4 -c:v libx265 -x265-params range=full -an output.mp4
[21:23:59 CEST] <wallnut> first command shows washed out colors in vlc and mpc-hc (both windows) but correct in mpv
[21:24:13 CEST] <wallnut> although input.mp4 has correct colors in vlc and mpc-hc
[21:24:56 CEST] <wallnut> i was creating the bug and wanted to write about what i tried, but now i'm a little confused :P
[21:25:15 CEST] <durandal_1707> wallnut: vlc and others support only limited range
[21:25:37 CEST] <durandal_1707> so convert range with scale filter, from full to limited
[21:26:15 CEST] <wallnut> i don't have enough knowledge to refute that information, but if vlc and others show full range correctly with source video, doesn't that mean they support it?
[21:30:20 CEST] <wallnut> from my limited user perspective if a video has full range in h264 and i encode it to h265 without any other changes, it still should be full range, shouldn't it?
[21:30:27 CEST] <wallnut> i'm probably wrong but i don't understand why
[21:31:07 CEST] <JEEB> if all things go right, it should go through (or if there's a range conversion, it should be done correctly)
[21:31:22 CEST] <JEEB> at this point I've no idea and I didn't nor do I currently have the time to test your issue out
[21:32:04 CEST] <JEEB> before in the history the swscale library didn't have range correctly so your full range stuff was likely to lose its marking but still stay the same
[21:32:13 CEST] <JEEB> oh, and this is expecting that the video encoder is OK
[21:53:41 CEST] <wallnut> i think durandal_1707 's advice about the scale filter did the trick
[21:54:11 CEST] <wallnut> for this command `ffmpeg -i input.mp4 -an -c:v libx265 -vf "scale=in_range=X:out_range=Y" output.mp4` i got these results
[21:54:17 CEST] <wallnut> X=full, Y=full => colors OK X=full, Y=limited => colors washed out X=limited, Y=full => colors OK X=limited, Y=limited => colors OK
[21:55:27 CEST] <wallnut> "OK" output files are binary identical
[21:58:12 CEST] <oerg866> hey by the way, ffmpeg still says 2017 :D
[21:58:15 CEST] <oerg866> in the copyright :D
[21:59:17 CEST] <durandal_1707> oerg866: you are using old binary
[21:59:30 CEST] <durandal_1707> here it says 2018
[22:01:36 CEST] <oerg866> oh whoops, my %path% was pointing to a folder that had an old version in it
[22:01:40 CEST] <oerg866> my bad :d
[22:21:29 CEST] <alexpigment> hey guys. i was encoding some videos to blu-ray and i came across a 720p30 video (i hate people who convert 720p60 to 720p30 by the way)
[22:21:55 CEST] <alexpigment> tried to use the x264 param "pulldown=double" but ffmpeg doesn't think it's a valid one
[22:22:04 CEST] <alexpigment> does anyone know if this was deprecated?
[22:22:56 CEST] <alexpigment> i suppose i could just encode to 720p60 and call it a day, but the pulldown method should shorten the encode time considerably
[22:22:59 CEST] <JEEB> I would almost recommend scanning x264's code base quickly for it
[22:23:46 CEST] <JEEB> < durandal_1707> i'm not gonna do it, its hard, and i can not test
[22:23:49 CEST] <JEEB> asdf
[22:23:52 CEST] <JEEB> copypasta fail
[22:23:58 CEST] <JEEB> static const char * const pulldown_names[] = { "none", "22", "32", "64", "double", "triple", "euro", 0 };
[22:24:06 CEST] <JEEB> so yes, x264.c has it
[22:24:49 CEST] <JEEB> and that is for OPT_PULLDOWN which has its string option as { "pulldown",    required_argument, NULL, OPT_PULLDOWN }
[22:25:15 CEST] <alexpigment> so in theory :pulldown=double: in a string of other args should work, right?
[22:26:16 CEST] <JEEB> ah, it might be that the string is limited to  cli
[22:26:24 CEST] <JEEB> not 100% sure though
[22:26:32 CEST] <JEEB> never tried to actually set that thing :P
[22:26:57 CEST] <JEEB> but it should be rather simple to encode a few frames and see
[22:27:35 CEST] <alexpigment> oh weird, i figured it out
[22:27:36 CEST] <JEEB> although it probably will need cfr mode as well on the encoder side
[22:27:59 CEST] <alexpigment> so i was using some older scripts that had "x264opts"
[22:28:14 CEST] <alexpigment> i've really never come across a reason to need x264-params
[22:28:16 CEST] <alexpigment> until just now
[22:28:20 CEST] <alexpigment> changing it to that fixed it
[22:28:48 CEST] <alexpigment> seems like a bug, but probably one that no one cares to fix since it's considered legacy syntax at this point
[22:29:15 CEST] <JEEB> x264-params uses a newer way of reading key=value pairs which doesn't support hacks like not having the value at all
[22:29:25 CEST] <JEEB> while x264opts has an old homebrew parsing thing
[22:29:50 CEST] <alexpigment> yeah, maybe i need to make sure everything also has a value while i'm at it
[22:30:08 CEST] <JEEB> I tried to remove x264opts at one point, but then basically got told that people wanted to be able to set booleans without a value
[22:30:20 CEST] <JEEB> I don't remember the exact discussion, it was a while ago
[22:30:42 CEST] <alexpigment> oh yeah, i've got a handful of options in here wih no values (force-cfr, open-gop, no-scenecut)
[22:31:05 CEST] <alexpigment> i guess it's just safe to put =1 on all of them?
[22:31:10 CEST] <JEEB> yes
[22:31:26 CEST] <JEEB> also fun if those got set because then someone actually implemented that hack :P
[22:33:19 CEST] <alexpigment> i mean it seems weird to get rid of the hack
[22:33:37 CEST] <alexpigment> like it's an efficient way to write a command
[22:33:50 CEST] <JEEB> a completely different person wrote a general key-value thing for the whole of FFmpeg
[22:33:57 CEST] <JEEB> or well, Libav maybe since it originates there probably
[22:34:12 CEST] <JEEB> but that person did not think of that as a requirement
[22:34:12 CEST] <alexpigment> anyway, i just noticed that my encoding didn't fail, but it does say it can't understand pulldown double. it's just a warning now with params, vs a failure with opts
[22:34:23 CEST] <alexpigment> maybe i need to update ffmpeg
[22:34:39 CEST] <JEEB> then new features just got written with the built-in dictionary parser
[22:35:12 CEST] <JEEB> if that "doesn't understand" comes from libx264 itself then it's just an incorrect thing
[22:35:15 CEST] <JEEB> lessee
[22:35:55 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/libx264.c;h=12379ff76364760b8d95a35f9d8a7a3711729fa9;hb=HEAD#l785
[22:36:10 CEST] <JEEB> so if you get that warning, then x264 told FFmpeg that it no habla espanol
[22:38:34 CEST] <alexpigment> yeah that's the one
[22:38:46 CEST] <alexpigment> so basically pulldown=double is broken
[22:39:55 CEST] <alexpigment> i wonder if 22 is the same as pulldown
[22:40:10 CEST] <alexpigment> er, the same as double
[22:41:02 CEST] <JEEB> ah, fun
[22:41:11 CEST] <JEEB> all of the API options are defined in common/base.c
[22:41:12 CEST] <JEEB> http://git.videolan.org/?p=x264.git;a=blob;f=common/base.c;h=a07d9c6b84d24accdd411b03f5cae9b0243380b2;hb=HEAD#l812
[22:41:46 CEST] <alexpigment> none of the other pulldown options work either
[22:42:00 CEST] <JEEB> so like it seemed with reading x264.c, it actually only works if you set the values to the struct
[22:42:48 CEST] <alexpigment> that last statement was above my understanding
[22:43:12 CEST] <JEEB> as in, currently it needs actual code plumbing specifically for those values
[22:43:26 CEST] <JEEB> or adding pulldown as an API option
[22:43:30 CEST] <JEEB> in x264
[22:44:09 CEST] <alexpigment> ah
[22:44:35 CEST] <alexpigment> so there's no way to work around it as far as you can see, right?
[22:44:54 CEST] <alexpigment> if so, i'll just go ahead and change fps to 60000/1001
[22:46:45 CEST] <JEEB> yea, it currently doesn't have an option in libx264.c on FFmpeg's side, and the string-based things don't have the logic there is in x264.c
[22:46:50 CEST] <JEEB> http://git.videolan.org/?p=x264.git;a=blob;f=x264.c;h=7688b60d733bec00a9ef8b76d670381402a1cdc0;hb=HEAD#l1905
[22:47:01 CEST] <JEEB> that's what the cli does
[22:49:44 CEST] <alexpigment> well, i'm over here just doing 60 for now
[22:49:49 CEST] <alexpigment> thanks for looking into that and confirming
[22:50:17 CEST] <alexpigment> ffmpeg is saying "Over 1000 frames duplicated", and i'm like "good, keep doing that"
[22:52:43 CEST] <JEEB> do it in the fps filter and it will not do that I think? :D
[23:13:14 CEST] <leewdch> can I make a video out of two frames making them 4 seconds long each?
[23:41:18 CEST] <kepstin> leewdch: a lot of container formats can't handle representing the duration of the last frame
[23:41:29 CEST] <kepstin> leewdch: that said, it should be ok if you have 8 seconds of audio
[23:42:27 CEST] <leewdch> how can that help me?
[23:43:07 CEST] <kepstin> a video player will hold the last frame in the video until the audio finishes, typically
[23:43:45 CEST] <kepstin> so if you have a video track with a frame at t=0, a frame at t=4, and an audio track that's 8s long, the playback will show the first frame for 4s, and the second frame for 4s.
[23:46:47 CEST] <leewdch> cant I just make a 8 seconds long silent audio and pipe it?
[23:47:10 CEST] <kepstin> ffmpeg can generate silent audio in a filter, no need for external processes
[00:00:00 CEST] --- Wed May  2 2018