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

[burek]

[00:00:25 CET] <alexpigment> right
[00:00:51 CET] <alexpigment> youtube provides progressive video with square pixels
[00:01:01 CET] <alexpigment> and dvd is interlaced video with non-square pixels
[00:01:06 CET] <therage3> o.o
[00:01:44 CET] <alexpigment> the non-square pixels is why dvd has a resolution of 720x480, but a display resolution of 640x480 (or 853x480 for widescreen)
[00:01:56 CET] <alexpigment> somewhere in the chain, that conversion has to happen
[00:02:07 CET] <alexpigment> for DVDs, it's the player
[00:02:23 CET] <alexpigment> Handbrake just takes that out of the equation so that the player can play the pixels as square
[00:02:30 CET] <therage3> for YouTube, it's their encoder and whatever slaps the video on their server
[00:02:42 CET] <alexpigment> yeah, and the encoder is just x264
[00:02:47 CET] <therage3> ?
[00:02:49 CET] <alexpigment> same as handbrake, ffmpeg
[00:02:51 CET] <therage3> how do you know that
[00:02:56 CET] <therage3> ????
[00:03:00 CET] <therage3> is that known?
[00:03:04 CET] <kepstin> well, they also use libvpx for the vp9 encodes :)
[00:03:11 CET] <alexpigment> i don't remember the details, but people around here know this
[00:03:12 CET] <therage3> O.O
[00:03:20 CET] <therage3> is that uh like
[00:03:22 CET] <alexpigment> to be clear, their H.264 encodes are done by x264
[00:03:24 CET] <therage3> something Google revealed?
[00:03:38 CET] <alexpigment> again, i don't remember the details. kepstin probably does
[00:03:38 CET] <kepstin> therage3: nah, you can figure it out by looking at properties of the encoded video
[00:03:49 CET] <therage3> ahh you mean the Stats for Nerds thingie
[00:03:52 CET] <therage3> that thing
[00:04:22 CET] <kepstin> well, no, that doesn't really say. But if you download the video and analyze the stream, you can figure it out.
[00:04:40 CET] <therage3> i see...........
[00:04:45 CET] <kepstin> most of what people know about youtube's video encoder, they figured out by uploading test videos then downloading the encoded video
[00:05:09 CET] <therage3> Hmmm some interesting shenanigans some people here do :)
[00:05:11 CET] <furq> it's known that they're using ffmpeg isn't it
[00:05:17 CET] <furq> which narrows the choice down a bit
[00:05:21 CET] <kepstin> they use a (fairly old) version of ffmpeg to decode at least some of the input formats
[00:05:32 CET] <alexpigment> furq: are you telling me they aren't using the cisco h264 encoder??? ;)
[00:05:37 CET] <therage3> O.o
[00:05:39 CET] <furq> we may never know
[00:06:23 CET] <kepstin> i suspect they aren't using ffmpeg to encode, given how they're known to break the file into segments and do distributed encodes, but there's no real way to tell.
[00:06:44 CET] <furq> i assumed they were using something else for vp9
[00:06:51 CET] <alexpigment> i know from 1) watching youtube and 2) having eyes, that they do not prioritize quality
[00:06:53 CET] <alexpigment> ;)
[00:06:57 CET] <furq> i wasn't aware they were doing distributed encoding for h264
[00:07:06 CET] <furq> but i guess it would make sense for them to do that
[00:07:11 CET] <iranen> every youtube video is vp9 and opus by default
[00:07:18 CET] <furq> no it's not
[00:07:20 CET] <therage3> what
[00:07:28 CET] <TD-Linux> it's pretty easy to determine they are just by seeing how long it takes them to encode a long upload.
[00:07:35 CET] <therage3> that's not even remotely true, i've used youtube-dl to pull the info
[00:07:41 CET] <therage3> and it isn't true that those are the things
[00:07:44 CET] <furq> it's h264 and aac by default for new videos until it hits a certain view count
[00:07:45 CET] <kepstin> hmm, I thought they were, but again - it's hard to tell. They might be doing a single h264 encode during the upload to have the video immediately ready, maybe? who knows.
[00:07:55 CET] <furq> on account of x264 is way faster than libvpx
[00:08:03 CET] <alexpigment> yeah, i've never really known the reason for why they have webm videos
[00:08:08 CET] <alexpigment> view count makes sense i guess
[00:08:17 CET] <furq> that's anecdotal fwiw
[00:08:22 CET] <kepstin> they don't do h264 encodes for 4k content, iirc
[00:08:22 CET] <therage3> kepstin: it's possible, note that when a video is uploaded, particularly higher quality ones, the low quality ones go up first, followed by the higher resolution ones later
[00:08:24 CET] <furq> i am not youtube
[00:08:26 CET] <alexpigment> i think all of their 4k stuff is webm
[00:08:35 CET] <furq> i think they still do h264? i might be wrong though
[00:08:39 CET] <furq> there's definitely h264 at 1440p
[00:08:50 CET] <alexpigment> furq: i'm specifically talking about 2160p
[00:08:51 CET] <kepstin> they do downscaled copies of 4k videos as h264
[00:08:56 CET] <kepstin> but the 4k itself is vp9 only
[00:09:01 CET] <therage3> it's easy to tell. just use youtube-dl on the video with -F flag
[00:09:04 CET] <therage3> and see what options it gives
[00:09:49 CET] <furq> 266          mp4        3840x2160  DASH video 19296k , avc1.640033, 24fps, video only, 148.41MiB
[00:09:55 CET] <furq> also
[00:09:58 CET] <furq> 138          mp4        7680x4320  DASH video 65785k , avc1.640033, 24fps, video only, 585.54MiB
[00:10:04 CET] <therage3> yah
[00:10:14 CET] <TD-Linux> it's dependent on video
[00:10:25 CET] <TD-Linux> I don't think they deleted old 4k h264 videos
[00:10:30 CET] <TD-Linux> also they change their mind every week
[00:10:33 CET] <kepstin> but yeah, from my youtube channel and some other observations, at some point last year it appeared that youtube wasn't doing vp9 encodes until hitting some view count. i haven't checked recently tho.
[00:10:35 CET] <therage3> yes. differently uploaded formats and containers get processed differently
[00:10:36 CET] <therage3> i think
[00:10:41 CET] <furq> 23:10:30 ( TD-Linux) also they change their mind every week
[00:10:44 CET] <furq> this much is very true
[00:10:47 CET] <therage3> wait, what?
[00:10:54 CET] <therage3> until *hitting some view count*?
[00:10:57 CET] <therage3> they do that??
[00:11:02 CET] <TD-Linux> I've had a couple of videos that got vp9 basically immediately
[00:11:04 CET] <furq> last time i checked my videos, yes
[00:11:05 CET] <alexpigment> TD-Linux: that is very true. i've got proof that they changed the encoding of a particular video at least 3 times. seemingly for no reason
[00:11:09 CET] <iranen> older videos may be mp4 still on youtube but seen mostly all new videos are vp9
[00:11:10 CET] <kepstin> they appeared to do it as of some time last year when i checked
[00:11:15 CET] <furq> all my videos below 150 views had no webm, all above had it
[00:11:25 CET] <furq> this was a couple of years ago so it's probably hopelessly outdated now
[00:11:30 CET] <furq> they'll have changed policy 18 times since then
[00:11:31 CET] <therage3> you have got to be kidding me, that's not even something they're upfront about, is it
[00:11:40 CET] <furq> i have actually noticed that recently though
[00:11:48 CET] <TD-Linux> it's not really relevant to the end user
[00:11:54 CET] <furq> i watch a lot of 2d arcade game superplays which look absolutely shit in h264
[00:12:01 CET] <therage3> ^
[00:12:11 CET] <furq> they always look shit until they hit about 150 views, then they mysteriously look fine
[00:12:12 CET] <therage3> some kinds of genres and videos, you can tell
[00:12:17 CET] <alexpigment> furq: tbf, that one vlog you did was really good and worthy of webm; the viewcount was secondary
[00:12:20 CET] <therage3> so to some end users, it does matter
[00:12:21 CET] <kepstin> therage3: IIRC, they always seem to (last I checked) do a minimum of one h264 and one vp8 encode as a baseline for compat.
[00:12:27 CET] <therage3> kepstin: i see
[00:12:30 CET] <furq> i did a vlog?
[00:12:35 CET] <therage3> lol
[00:12:35 CET] <alexpigment> furq: i'm joking
[00:12:56 CET] <furq> i was really worried for a minute there
[00:13:02 CET] <kepstin> and any other encodes you get are bonus, and usually appear later.
[00:13:03 CET] <furq> i thought i might have become a youtuber without realising
[00:13:09 CET] <furq> hey guys,
[00:13:26 CET] <kepstin> don't forget to like and subscribe ;)
[00:13:31 CET] <alexpigment> sorry. it seemed like a good joke in my head to insinuate that youtube thought your video was webm-worthy
[00:13:46 CET] <furq> you should never joke about something as serious as someone being a vlogger
[00:13:47 CET] <alexpigment> i don't understand the rhyme or reason for webm vs mp4 at all tbh
[00:14:01 CET] <alexpigment> furq: I'm a habitual line-stepper
[00:14:12 CET] <alexpigment> stepping over the line is what I do best
[00:14:13 CET] <furq> cocaine's a hell of a drug
[00:14:38 CET] <alexpigment> yes, it certainly is, rick
[00:14:54 CET] <kepstin> for all we know, whether or not you get a vp9 immediately might be dependent on whether they have spare/unused compute capacity handy. or just an RNG.
[00:15:26 CET] <furq> viewcount is my best guess just because every time i've noticed no webm version, it's a low viewcount video
[00:15:30 CET] <furq> but that might equally well be age
[00:19:37 CET] <oerg866> so we meet again, people of #ffmpeg :D
[00:19:46 CET] <oerg866> I'd like to get rid of all of this video noise: https://i.snag.gy/3k0TUC.jpg
[00:20:00 CET] <furq> good luck
[00:20:12 CET] <oerg866> thanks :P
[00:21:01 CET] <oerg866> it's a digitized VHS so theoretically the frequency of the noise exceeds the bandwidth the video had to begin with
[00:21:15 CET] <furq> i was about to say that that's more noise than video
[00:21:17 CET] <oerg866> so in my naive mind it should be good with like a "low pass filter" on that video
[00:21:18 CET] <redrabbit> you need that algo they use in ncis
[00:21:23 CET] <alexpigment> this is a capture problem and needs to be dealt with before it gets digitized
[00:21:38 CET] <oerg866> no this was recorded off an aerial
[00:21:40 CET] <redrabbit> "computer, enhance"
[00:21:46 CET] <oerg866> it literally is that bad on the tape
[00:22:09 CET] <oerg866> but this is really rare footage so it'd be a shame not to at least give it a whirl
[00:22:29 CET] <furq> i mean there might be some denoise filter that is specifically good at this
[00:22:41 CET] <furq> any general-purpose one is just going to smear the hell out of it
[00:22:50 CET] <oerg866> yeah general purpose is bad because it will do vertical denoising too
[00:23:03 CET] <oerg866> but tv signal is line by line so the noise in the lines is independent anyway
[00:23:12 CET] <furq> maybe one of the libavfilter gurus will have some ideas
[00:23:29 CET] <oerg866> a line based blur which is effectively a low pass filter would be good here i think but again, no experience with the fiilters in ffmpeg :S
[00:24:57 CET] <therage3> oerg866: maybe this? https://forum.videohelp.com/threads/352541-Reduce-Video-Noise-With-ffmpeg-command
[00:25:19 CET] <therage3> oerg866: full disclosure, that thread looked promising, but i don't know much about this; ymmv
[00:27:49 CET] <alexpigment> oerg866: have you tried another VCR by chance?
[00:28:12 CET] <therage3> alexpigment: i just did some testing. apparently if you ask it to keep source framerate, with detelecine filter turned on, it keeps it at 29.97
[00:28:26 CET] <alexpigment> again, i know I seem like I'm harping on this, but as a person who has done a TON of vhs > digital work, it's always best to try two different VCRs, specifically one high end JVC and one high end Panasonic
[00:28:30 CET] <therage3> alexpigment: it doesn't reduce it to 23.whatever
[00:28:37 CET] <oerg866> alexpigment: It's not the VCR, this was captured off a professional grade machine (panasonic AG-7350)
[00:28:45 CET] <alexpigment> therage3: good to know that I had reason to distrust that option :)
[00:28:54 CET] <oerg866> and i know the exact reason why this particular episode is so noisy
[00:29:09 CET] <alexpigment> ok, just checking
[00:29:15 CET] <alexpigment> i'll go back to my corner now ;)
[00:29:28 CET] <oerg866> usually the guy who recorded this would record the show off a local station, but when he was out of town he had to catch the rerun on a station that was in another part of the country
[00:29:29 CET] <therage3> alexpigment: i used a small chapter from one of the videos to do a quick encode and comparison. now i need to actually extract the frames from both and see wtf the difference is o.O
[00:29:38 CET] <therage3> alexpigment: because visually both clips look a priori identical
[00:29:44 CET] <furq> alexpigment: i suspect i know the answer to this, but i might as well get confirmation
[00:29:48 CET] <furq> https://www.youtube.com/watch?v=bLozqekEnGQ
[00:29:49 CET] <therage3> but if they have a different frame rate and have the exact same length
[00:29:52 CET] <furq> there's no possible way this came off a vhs, right
[00:29:54 CET] <therage3> they must have different frames
[00:30:40 CET] <furq> i assume the guy has got the actual source from somewhere but i can't find any evidence of them being leaked anywhere but youtube
[00:30:45 CET] <oerg866> <furq> there's no possible way this came off a vhs, right <-- chroma resolution is too high and lack of head switching noise at the bottom
[00:30:50 CET] <furq> right
[00:31:24 CET] <furq> i notice some delogoing in the top right corner as well
[00:32:01 CET] <furq> i actually wonder if this is an hdtv capture from some network rebroadcast
[00:32:51 CET] <oerg866> Someone probably got a copy of the master broadcast tape
[00:33:00 CET] <oerg866> not sure if stuff was archived digitally in 1995 yet
[00:33:04 CET] <furq> it's got to be one or the other yeah
[00:33:16 CET] <therage3> wat
[00:33:22 CET] <furq> but if the masters had been leaked i'd expect to be able to find it outside of youtube lol
[00:33:40 CET] <furq> maybe it's just someone very honest
[00:33:40 CET] <therage3> the master broadcast tape? who has access to that other than the network
[00:34:03 CET] <oerg866> copies of that get made
[00:34:17 CET] <furq> a lot of different networks used the bbc commentary
[00:34:24 CET] <furq> so there'll be a bunch of different masters for all of those
[00:34:30 CET] <furq> plus any copies that have been made
[00:34:44 CET] <therage3> so maybe some "slipped" through the cracks and made its way to YouTube...?
[00:34:56 CET] <furq> yeah it's just weird that none of them seem to have made it anywhere else
[00:35:13 CET] <furq> the guy's got a bunch of different races in this quality
[00:35:24 CET] <oerg866> also networks are "losing" their tapes
[00:35:27 CET] Action: therage3 raises an eyebrow
[00:35:36 CET] <oerg866> they get rid of their analog archives and give the tapes to employees and stuff
[00:35:42 CET] <therage3> i wonder if this guy used to work at one of these channels......
[00:35:46 CET] <therage3> oerg866: interesting
[00:37:21 CET] <furq> but yeah there are channels that rebroadcast these races
[00:37:28 CET] <furq> and the delogoing makes me wonder if that's where this is from
[00:37:35 CET] <therage3> alexpigment: lol so one of the clips has 1913 frames (30fps), the other has 1531 (24fps)
[00:37:39 CET] <furq> although that'd be a tiny logo
[00:38:46 CET] <therage3> Ahhh interesting
[00:38:48 CET] <therage3> I see
[00:38:57 CET] <therage3> so the duplicate isn't decimated in the 30fps clip
[00:39:01 CET] <therage3> that's where the difference is
[00:40:40 CET] Action: therage3 has learned enough about video processing today :D
[01:09:49 CET] <rajkosto> hmm if i try to use cuvid via ffmpeg send_packet always returns "no frame!" unless i enable ctx->flags2 |= AV_CODEC_FLAG2_CHUNKS; then it doesnt, but i still never get frames out of receive_frame
[01:27:15 CET] <alexpigment> therage3: so did it seem to keep the patterns through the whole video?
[01:27:36 CET] <therage3> alexpigment: i have no clue, for some reason ffmpeg's CLI command didn't nuke it all properly
[01:27:41 CET] <therage3> yet handbrake worked
[01:28:05 CET] <therage3> and i'm not even going to attempt to explain it because that's going down another rabbithole
[01:28:25 CET] <alexpigment> therage3: it's possible that ffmpeg's detelecine filter expects the pattern to be the same the whole way through and handbrake's does a rescan of the patterns at certain points
[01:28:35 CET] <therage3> yeah, who knows
[01:28:44 CET] <therage3> also now i'm terribly confused... for two reasons
[01:28:45 CET] <alexpigment> because the most likely place for the pattern to get 'off' is at the commercial breaks
[01:29:05 CET] <therage3> get this: https://forums.macrumors.com/threads/handbrake-detelecine-decomb-batman-tas.1882825/
[01:29:15 CET] <therage3> someone there said "Don't mess with frame rate (leave it same as source)."
[01:29:27 CET] <therage3> and here's something else:
[01:29:59 CET] <therage3> https://handbrake.fr/docs/en/latest/cli/cli-guide.html
[01:30:11 CET] <therage3> go down to the "--detelecine[=string]" parameter
[01:30:24 CET] <therage3> "Note: this filter drops duplicate frames to
[01:30:24 CET] <therage3>                            restore the pre-telecine framerate"
[01:30:26 CET] <therage3> wat
[01:30:39 CET] <therage3> but i looked at, it's still 29.97
[01:30:44 CET] <therage3> what the hell is going on here
[01:30:50 CET] <alexpigment> who knows
[01:31:11 CET] <alexpigment> the saving grace is that if you're detelecining from NTSC, your target frame rate is always going to be 23.976
[01:31:41 CET] <alexpigment> are you sure you had it on "same as source" for the 30fps one?
[01:31:42 CET] <therage3> but if you leave it as source, and it chooses 29.97, what on earth is it using as extra frames?
[01:31:56 CET] <alexpigment> extra frames are always duplicates
[01:32:04 CET] <therage3> because the detelecine thing according to handbrake's documentation nukes duplicates
[01:32:07 CET] <alexpigment> right
[01:32:09 CET] <therage3> no, you see, that's the thing
[01:32:18 CET] <therage3> the duplicates are supposed to be done
[01:32:20 CET] <therage3> gone*
[01:32:20 CET] <alexpigment> but then it adds new ones back in if you specify a higher framerate
[01:32:26 CET] <therage3> lol wat
[01:32:37 CET] <alexpigment> ok, say i have a video that's 15fps
[01:32:38 CET] <alexpigment> natively
[01:32:43 CET] <therage3> mhm
[01:32:45 CET] <alexpigment> and i tell handbrake to output to 30fps
[01:32:50 CET] <therage3> sure
[01:32:52 CET] <alexpigment> it *creates* duplicates
[01:32:59 CET] <therage3> it has to
[01:33:08 CET] <therage3> unless you tell it to telecine
[01:33:10 CET] <therage3> or whatever
[01:33:16 CET] <alexpigment> likewise, if i detelecine to 23.976 and then specify 29.976 output, it creates new duplicate frames
[01:33:31 CET] <therage3> yeah, that does make sense
[01:33:48 CET] <therage3> here's another wrench thrown into the machinery though...
[01:33:57 CET] <alexpigment> now i'm not sure where the problem was - either it was set to "same as source" and failed, or it was set to 29.97 explicitly - but it made up new frames
[01:34:28 CET] <alexpigment> either way, i always do both, because i know the desired result, and handbrake can only infer the desired result
[01:34:31 CET] <therage3> no, i set it to same as source
[01:34:43 CET] <alexpigment> they probably have a bug somewhere
[01:34:46 CET] <alexpigment> who knows
[01:34:51 CET] <therage3> ._.
[01:34:55 CET] <therage3> ok get this
[01:34:59 CET] <therage3> from #handbrake 's official channel here
[01:35:00 CET] <therage3> https://pastebin.com/raw/ADG1gkaA
[01:35:01 CET] <therage3> lol
[01:35:04 CET] <therage3> i just asked there
[01:35:16 CET] <therage3> this is driving me insane
[01:35:36 CET] <alexpigment> haha
[01:35:54 CET] <alexpigment> well, don't trust them. if you know it's telecined, just set the framerate to 23.976
[01:35:56 CET] <alexpigment> and call it a day
[01:36:01 CET] <therage3> LMAO
[01:36:06 CET] <alexpigment> as for decomb, i don't like that option
[01:36:15 CET] <therage3> i don't even know what that is, don't care
[01:36:27 CET] <therage3> video processing has messed with my head enough for one century :D
[01:36:31 CET] <alexpigment> i get why people use it, but it's a filter that's made to achieve passable results for people who don't know what their content is
[01:36:41 CET] <therage3> i mean, i can infer it's to get rid of combing artifacts
[01:36:46 CET] <therage3> but other than that
[01:36:53 CET] <alexpigment> well, here's the deal
[01:37:02 CET] <alexpigment> combing artifacts come from one of two scenarios:
[01:37:08 CET] <alexpigment> a) the video is telecined
[01:37:11 CET] <alexpigment> b) the video is interlaced
[01:37:36 CET] <alexpigment> if you know whether your content is telecined or true interlaced, you use either detelecine or deinterlace
[01:37:54 CET] <alexpigment> decomb is like "uhh, just get rid of any lines by doing some blurring or line doubling"
[01:38:14 CET] <alexpigment> it's never a good replacement
[01:38:34 CET] <therage3> omg
[01:38:39 CET] <therage3> that's a horrific solution
[01:38:44 CET] <alexpigment> now, the person in there that said he also puts it on is right in that there are some cases where the pattern gets weird at transitions, but I treat those on a case by case basis
[01:38:54 CET] <therage3> i mean i guess it needs to be done when you have some bizarre mixed interlaced and telecined video
[01:38:56 CET] <alexpigment> right
[01:39:00 CET] <therage3> and the telecine filter is confused
[01:39:28 CET] <jfmcarreira> heyy guys. I am using the following code to read stream using libav: http://dpaste.com/1HAP5PQ. However the function av_read_frame is always returning EOF error
[01:40:51 CET] <alexpigment> therage3: still though, i'd rather figure out how to get a properly detelecined video. detelecining gives the best vertical resolution, because you get the full 480 rather than line doubled 240
[01:41:00 CET] <therage3> same here
[01:41:31 CET] <therage3> i don't know if this is just how stuff was done back then, but the mastering on this DVD is giving me such a headache
[01:42:02 CET] <alexpigment> well, it was probably just taken from the source beta tapes
[01:42:06 CET] <alexpigment> or whatever they used back then
[01:42:17 CET] <alexpigment> in which case, the telecining was *burned into* the tape
[01:42:39 CET] <therage3> so the original source they used was already hard telecined, right into the footage
[01:42:45 CET] <therage3> so we're also stuck with it
[01:42:46 CET] <alexpigment> i doubt they went back to a film master because they'd have to add credits back in and that sort of thing
[01:43:12 CET] <therage3> well, consider that this was a Saturday morning cartoon that only lived two seasons, and was cancelled in 1995
[01:43:15 CET] <alexpigment> well anytime you add video effects on, you're probably already in "video" (telecined) rather than "film"
[01:43:24 CET] <therage3> so the original 16/35mm film elements still existing are next to zilch
[01:43:26 CET] <alexpigment> what cartoon was it, out of curiosity?
[01:43:34 CET] <therage3> Sonic the Hedgehog (commonly known as SatAM)
[01:43:39 CET] <alexpigment> there's a company called shout factory that does great re-releases of stuff like that
[01:43:44 CET] <alexpigment> ah gotcha
[01:43:45 CET] <therage3> ...... that's the company
[01:43:45 CET] <therage3> lol
[01:43:50 CET] <therage3> Shout! Factory
[01:44:10 CET] <jfmcarreira> why am i getting EOF error when calling av_read_frame for the first time?
[01:44:14 CET] <alexpigment> well, shout factory generally does good stuff, but they can only do what they can with the masters that are available
[01:44:27 CET] <therage3> alexpigment: i see, so this is more DiC/Sega's fault than Shout! Factory's
[01:44:54 CET] <alexpigment> on the other hand, they did Pee-Wee's Playhouse by taking the original film and redoing all the effects on top of it. it was a crazy amount of work, but that's why there's a blu-ray available
[01:45:00 CET] <alexpigment> you can only do HD if you have the source film
[01:45:05 CET] <therage3> exactly
[01:45:22 CET] <therage3> and like i said, unfortunately, that source film, the film elements, are more than likely not around anymore
[01:45:57 CET] <alexpigment> yeah, they're either gone or hidden in a box somewhere
[01:46:33 CET] <therage3> if they're hidden in a box somewhere... i mean, this show does have a huge cult following
[01:46:37 CET] <therage3> so, knock on wood
[01:46:37 CET] <therage3> :D
[01:47:22 CET] <alexpigment> i'm guessing not enough of a cult following to pay for someone to rescan the episodes from film
[01:47:35 CET] <alexpigment> and re-do any video-based overlays
[01:47:49 CET] <alexpigment> that's a huge amount of money that most companies can't justify
[01:47:57 CET] <alexpigment> but they did it with star trek TNG
[01:48:32 CET] <alexpigment> and that's really impressive, but they had to recreate so many assets and I think there were some cases where they couldn't find the original scenes so they had to go back to the video masters (SD)
[01:48:50 CET] <alexpigment> maybe they finally found them by the end, but the documentary definitely mentioned scenes like that
[01:48:52 CET] <therage3> yeah, and...
[01:49:14 CET] <therage3> there was also additional drama involving one of the former writers of the now defunct Archie comics for Sonic the Hedgehog
[01:49:20 CET] <therage3> that made Sega keep their distance from SatAM
[01:49:40 CET] <alexpigment> interesting
[01:49:49 CET] <therage3> yeah, it's ... crazy
[01:51:01 CET] <therage3> alexpigment https://pastebin.com/raw/P5VwycKy
[01:51:03 CET] <therage3> no answer yet
[01:51:04 CET] <therage3> lol
[01:51:35 CET] <therage3> you know if this is a bug i'm going to their mailing list
[01:51:38 CET] <therage3> and reporting it
[01:51:48 CET] <alexpigment> well, i can do a quick test to confirm this on my end
[01:52:03 CET] <therage3> uh sure, you'll see duplicate frames more than likely but go ahead
[01:52:07 CET] <therage3> it'd be useful to compare results
[01:53:57 CET] <alexpigment> well, it looks like i'm using a handbrake build from 2013
[01:53:58 CET] <alexpigment> but stil
[01:54:00 CET] <alexpigment> *still
[01:54:02 CET] <alexpigment> we'll see what happens
[01:54:08 CET] <therage3> k
[01:54:15 CET] <alexpigment> this is truly a not-broken-don't-fix situation
[01:54:36 CET] <alexpigment> (meaning, i'm not downloading a new one because the current one works)
[01:55:10 CET] <therage3> sure yeah
[01:57:07 CET] <alexpigment> 29.97
[01:58:15 CET] <therage3> mhm
[01:58:29 CET] <alexpigment> again, this is an old version, but if yours is new, then that tells me this is at least a 4-year-old bug
[01:58:31 CET] <alexpigment> OR
[01:58:50 CET] <alexpigment> some developer saw "same as source" and misunderstood it, and changed some code
[01:58:57 CET] <alexpigment> because to me, that's confusing as hell
[01:59:23 CET] <alexpigment> same as source *would* be 29.97
[01:59:33 CET] <therage3> yeah, especially in light of soft/hard telecine differences
[01:59:35 CET] <alexpigment> there needs to be an "auto" option
[01:59:47 CET] <therage3> yeah, or "Recommended"
[01:59:50 CET] <alexpigment> sure
[01:59:59 CET] <alexpigment> something that implies that the frame rate might change due to filters
[02:01:30 CET] <alexpigment> same as source also ignores deinterlacing fwiw
[02:01:53 CET] <alexpigment> actually, let me do that test again
[02:02:00 CET] <alexpigment> i chose "slow" rather than bogb
[02:02:01 CET] <alexpigment> *bob
[02:02:32 CET] <alexpigment> yeah, same result
[02:02:34 CET] <alexpigment> 29.97
[02:03:08 CET] <therage3> i see
[02:03:38 CET] <alexpigment> anyway, you can let them know that detelecine and deinterlace both keep the same frame rate as the source, rather than automatically using 23.976 or 59.94, respectively
[02:05:12 CET] <furq> i know this is late but i would like to reaffirm that handbrake's decomb filter sucks
[02:05:42 CET] <alexpigment> therage3: oh, I just tried something else
[02:05:49 CET] <alexpigment> i think you have to set it to variable frame rate
[02:05:56 CET] <therage3> alexpigment: lol wat
[02:06:02 CET] <therage3> don't most players derp on that
[02:06:10 CET] <alexpigment> well, they're using it in a weird way
[02:06:15 CET] <furq> is this hybrid interlaced/telecined
[02:06:22 CET] <furq> or is handbrake just weird
[02:06:28 CET] <therage3> i _think_ it's pure hard telecine
[02:06:53 CET] <alexpigment> furq: it seems that when you set it to constant framerate + same as source (frame rate), they honor that very literally
[02:06:59 CET] <furq> lol
[02:07:10 CET] <furq> i'm not hugely surprised that handbrake is getting stuff horribly wrong
[02:07:31 CET] <alexpigment> yeah, i'm not either. it's a good tool for what it is, but it has problems
[02:07:48 CET] <furq> you might be better off using ffmpeg
[02:07:51 CET] <alexpigment> and a lot of those problems - for me - are that the defaults get in the way of people who know what they're doing
[02:08:23 CET] <furq> ivtc is something i've always tried my best to avoid though so idk what combination of filters is recommended these days
[02:08:25 CET] <therage3> exactly, right??
[02:08:36 CET] <alexpigment> furq: well, this all started because therage3 has a video that ffmpeg's detelecine filter didn't handle right because the pattern changed. i recommended handbrake because their detelecine is actually pretty reliable in my experience, although i always set the destination frame rate explicitly
[02:08:50 CET] <furq> oh
[02:08:59 CET] <therage3> yeah, and then it turned out that in their support channel here on freenode, their staff was like "lol no dont do that leave it as source"
[02:09:05 CET] <alexpigment> i honestly leave everything as interlaced for the most part, but then again, i deal with a lot of truly interlaced content
[02:09:13 CET] <furq> how about the pullup filter
[02:09:19 CET] <therage3> the what now?
[02:09:27 CET] <furq> there are lots of filters for ivtc in ffmpeg
[02:09:28 CET] <alexpigment> pullup is just for soft telecine, right?
[02:09:32 CET] <therage3> o.o
[02:09:38 CET] <furq> Pulldown reversal (inverse telecine) filter, capable of handling mixed hard-telecine, 24000/1001 fps progressive, and 30000/1001 fps progressive content.
[02:09:41 CET] <furq> apparently
[02:09:49 CET] <alexpigment> oh nice
[02:09:52 CET] <therage3> wait
[02:09:53 CET] <therage3> WHAT
[02:09:54 CET] <alexpigment> well, i'll have to check that out sometime
[02:09:59 CET] <therage3> where the hell was this!!!
[02:10:01 CET] <furq> !filter pullup
[02:10:01 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#pullup-1
[02:10:21 CET] <furq> i couldn't tell you how good it actually is
[02:10:33 CET] <furq> by all accounts people still pull out avisynth/vapoursynth for hybrid interlaced/telecined material
[02:11:09 CET] <furq> autodetecting pattern changes is always going to be imperfect
[02:12:13 CET] <alexpigment> based on the settings available for this, i wonder how good it is when you don't specify those settings
[02:12:22 CET] <therage3> there's no defaults? ._.
[02:12:25 CET] <therage3> ugh
[02:12:33 CET] <alexpigment> i didn't say there wasn't
[02:12:47 CET] <alexpigment> just that you can tell it to ignore pixels on the top, bottom, left and right
[02:12:48 CET] <therage3> no like
[02:12:55 CET] <therage3> ah
[02:12:59 CET] <furq> there's also fieldmatch,decimate
[02:13:14 CET] <alexpigment> i think he tried that yesterday with little success, right?
[02:13:17 CET] <therage3> i remember someone told me about that
[02:13:19 CET] <therage3> in here, even
[02:13:22 CET] <therage3> JEEB i think it was
[02:13:33 CET] <furq> yeah i seem to remember that's the preferred way now
[02:15:06 CET] <therage3> alexpigment: "For best results (without duplicated frames in the output file) it is necessary to change the output frame rate. For example, to inverse telecine NTSC input:"
[02:15:09 CET] <therage3> from there
[02:15:15 CET] <therage3> that's precisely what you were doing
[02:15:21 CET] <therage3> in Handbrake
[02:15:22 CET] <alexpigment> yeah
[02:15:25 CET] <alexpigment> well, here's the thing
[02:15:44 CET] <therage3> alexpigment: also that Bradley guy just got back to me, he said (lol) change to variable framerate and source
[02:15:49 CET] <therage3> let's try
[02:15:53 CET] <alexpigment> if there's a filter that's decimating based on similarity between frames, i don't want that to cause the frame rate to change when nothing is going on (e.g. black frames)
[02:16:07 CET] <alexpigment> so i set the frame rate explicitly
[02:16:29 CET] <alexpigment> but i think with the pullup thing, it's saying that because your output will be VFR for truly mixed content
[02:16:44 CET] <therage3> yeah i see
[02:17:00 CET] <alexpigment> i personally would just leave that stuff as interlaced
[02:17:10 CET] <alexpigment> or perhaps go to 59.94 if i needed progressive
[02:17:29 CET] <alexpigment> either way, there's a million ways to do all this, sadly
[02:17:42 CET] <therage3> so i see ._.
[02:18:12 CET] <alexpigment> so i just usually avoid the hassle, leave it as interlaced, and make sure to use a player that knows how to deinterlace properly (e.g. Kodi, Windows Media Player)
[02:18:30 CET] <alexpigment> and I sit back and let the smooth frames lull me into a satisfied stuper
[02:18:38 CET] <therage3> in any case, i guess this variable frame rate thing may work
[02:18:41 CET] <therage3> let's see what it does
[02:18:43 CET] <alexpigment> yep
[02:18:54 CET] <alexpigment> it worked on my end - at least for deinterlace
[02:19:00 CET] <alexpigment> but the frame rate was a tiny bit off the spec
[02:19:20 CET] <alexpigment> 59.907 instead of 59.97
[02:19:24 CET] <therage3> o.o
[02:19:30 CET] <alexpigment> that's actually not uncommon
[02:19:36 CET] <furq> yeah if it is a straight detelecine it'll be cfr output
[02:19:40 CET] <furq> so maybe bradley just sucks
[02:19:40 CET] <alexpigment> sometimes it's the container that does it
[02:19:50 CET] <alexpigment> haha
[02:19:55 CET] <alexpigment> good ol' bradley
[02:20:14 CET] <therage3> hahahahahaha
[02:20:35 CET] <therage3> well, i guess the variable option covers all your bases
[02:20:50 CET] <therage3> if it's a standard patterned hard telecine, it'll theoretically come out cfr
[02:21:16 CET] <alexpigment> try a test (preview) of like 30 seconds or so and see if it actually comes out at 23.976
[02:21:33 CET] <therage3> yeah, i use this 1:04 intro theme from the show to test it out
[02:21:34 CET] <alexpigment> it could be slightly off, depending on if they're doing some additional decimating
[02:22:10 CET] <therage3> i cannot believe how much i learned today o.o
[02:23:20 CET] <alexpigment> in no time, you'll be talking to your friends and loved ones about how you defeated this hard telecined video, and they will absolutely love hearing about it ;)
[02:23:48 CET] <therage3> ok, what the ....
[02:23:59 CET] <therage3> what spec is effing 24.54 fps now??
[02:24:03 CET] <alexpigment> working with video on a deep level is a lonely hobby or job. no one understand what the hell you're talking about
[02:24:03 CET] <therage3> is this thing trolling me?
[02:24:09 CET] <therage3> that's closer to the PAL broadcast standard
[02:24:10 CET] <alexpigment> therage3: that's what I figured
[02:24:16 CET] <alexpigment> it's not perfect
[02:24:23 CET] <therage3> this thing has to be trolling me
[02:24:24 CET] <therage3> holy hell
[02:24:26 CET] <alexpigment> set it to 23.976 and call it a day
[02:24:40 CET] <alexpigment> tell bradley to suck it as well ;)
[02:24:40 CET] <furq> if you cropped a portion out then that could maybe be one extra frame
[02:24:49 CET] <furq> depending on how the tool you're using is calculating the framerate
[02:24:58 CET] <therage3> it's VLC
[02:25:05 CET] <therage3> i dunno how VLC does it
[02:25:12 CET] <furq> i wouldn't trust vlc to tell me what a traffic cone looks like
[02:25:17 CET] <therage3> LMAO
[02:25:19 CET] <alexpigment> haha
[02:25:25 CET] <therage3> ok hold on then
[02:25:25 CET] <furq> ask ffprobe
[02:25:26 CET] <alexpigment> usually *i'm* the one bashing vlc in here
[02:25:28 CET] <therage3> let me ffprobeit
[02:25:50 CET] <alexpigment> and offending vlc developers who are trying to defend the shortcomings of the software
[02:25:59 CET] <therage3> Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, smpte170m/smpte170m/bt709), 720x480 [SAR 8:9 DAR 4:3], 3371 kb/s, 24.54 fps, 120 tbr, 90k tbn, 180k tbc (default)
[02:26:01 CET] <therage3> same
[02:26:07 CET] <furq> neat
[02:26:12 CET] <therage3> VLC is surprise surprise, correct here
[02:26:12 CET] <therage3> lol
[02:26:21 CET] <furq> i mean it is right sometimes
[02:26:24 CET] <furq> but i'd always get a second opinion
[02:26:31 CET] <alexpigment> agreed
[02:27:14 CET] <alexpigment> admittedly, one of the advantages of vlc is that it kinda ignores a lot of metadata and brute forces what it knows about a video. for videos that aren't made correctly, this can sometimes mean it's the only play that plays the video
[02:27:44 CET] <alexpigment> *player
[02:27:52 CET] <therage3> yeah, i've had a bunch of players tell me a video is corrupt and refuse to play it
[02:28:06 CET] <therage3> VLC plays it, but when it gets to the corrupt section, acts up briefly, but resumes after it passes
[02:28:11 CET] <furq> where did you get that clip from btw
[02:28:13 CET] <furq> is that from handbrake
[02:28:27 CET] <therage3> the one i ran through ffprobe? yeah
[02:28:31 CET] <furq> fun
[02:28:32 CET] <therage3> the source is a DVD
[02:28:46 CET] <alexpigment> he detelecined with setting the frame rate to "variable" while on same as source
[02:28:53 CET] <therage3> ^
[02:28:59 CET] <furq> yeah that just sounds like their detelecine filter isn't very good
[02:28:59 CET] <therage3> that's the origin of the variable frame rate
[02:29:09 CET] <therage3> aaaaand now i'm ocd again
[02:29:15 CET] <therage3> o.o
[02:29:21 CET] <furq> maybe it's trying to do some smart detelecining and leaving some dup frames in
[02:29:22 CET] <alexpigment> furq: but honestly, it works pretty well, as long as you set a CFR
[02:29:54 CET] <alexpigment> i think it does something intelligent, which is why I tend to use it over ffmpeg for this particular scenario
[02:30:21 CET] <alexpigment> it also drops dupe frames pretty intelligently, which comes in handy when I have a 60p source that was originally 24fps
[02:30:27 CET] <therage3> the question is, if you set their detelecine filter to "Default" settings and force 23.976 fps, will there ever be a loss of any frame? like an original progressive frame, gone
[02:30:31 CET] <furq> lol
[02:30:34 CET] <furq> apparently it's using -vf pullup
[02:30:42 CET] <alexpigment> well, there you go :)
[02:30:46 CET] <alexpigment> maybe i should start using pullup
[02:31:03 CET] <furq> looks like its own implementation of it though
[02:31:08 CET] <therage3> oh
[02:31:10 CET] <therage3> so not ffmpeg's_
[02:31:11 CET] <therage3> ?
[02:31:40 CET] <furq> https://github.com/HandBrake/HandBrake/blob/master/libhb/detelecine.c
[02:31:48 CET] <alexpigment> given that handbrake is highly invested in the DVD ripping scene, they probably put some extra TLC into that filter
[02:32:20 CET] <furq> does the clip have any duplicate frames left
[02:32:39 CET] <furq> if it doesn't then i would guess it is actually doing the right thing and you don't have a fixed telecine pattern
[02:32:49 CET] <furq> which is extremely common for cartoon intros and stuff
[02:32:59 CET] <therage3> LOL
[02:33:04 CET] <therage3> that is EXACTLY what i have here
[02:33:08 CET] <therage3> the intro to a cartoon
[02:33:11 CET] <furq> enjoy skipping through 1350 frames
[02:33:12 CET] <therage3> that explains it
[02:33:13 CET] <furq> and yeah i read up
[02:33:31 CET] <alexpigment> the intros in particular (and outros) i wouldn't trust to be true telecined tbh
[02:33:32 CET] <therage3> well, that's the  thing, i actually need to look at the original to see if _that_ has any duplicates
[02:33:52 CET] <alexpigment> just because they might doing the credits in video on top of the telecined footage
[02:34:07 CET] <alexpigment> in which case, i'd still just force it to 23.976
[02:34:26 CET] <therage3> the intro doesn't have credits, and fortunately the outro is just a still image with text changing
[02:34:28 CET] <alexpigment> or again, leave it as interlaced if there's some visual value to having smooth animations on the credits
[02:35:51 CET] <alexpigment> therage3: the source will inherently have duplicates though, right?
[02:36:04 CET] <alexpigment> you mentioned looking at the source
[02:36:14 CET] <alexpigment> or rather, the "original"
[02:36:21 CET] <therage3> right, the DVD source
[02:36:38 CET] <alexpigment> yeah, it's telecined, so you're going to see that pattern of dupe frames
[02:36:38 CET] <therage3> and then one has to wonder how their filter decided to deal with those
[02:36:55 CET] <therage3> no i mean
[02:36:59 CET] <therage3> outside of the pattern
[02:37:06 CET] <alexpigment> oh i see
[02:37:09 CET] <therage3> something that's part of the _animation_ intendedby the animators
[02:37:20 CET] <therage3> like something that's still
[02:37:23 CET] <alexpigment> yeah that can be hard to tell
[02:37:37 CET] <therage3> yeah, and who is going to tell the filter ._.
[02:37:38 CET] <therage3> lol
[02:37:40 CET] <alexpigment> i just try to find a long panning scene
[02:37:47 CET] <therage3> it'll just go DECIMATE AAAAAAAAAHHHHHHH
[02:37:49 CET] <therage3> lol
[02:37:56 CET] <alexpigment> well, filters are surprisingly good about seeing the differences in frames that humans aren't
[02:38:02 CET] <therage3> o.o
[02:38:04 CET] <alexpigment> because in analog sources, there will be a difference in grain
[02:38:12 CET] <therage3> right
[02:38:45 CET] <alexpigment> you have to sort of turn your brain off and look for differences in grain rather than differences in the construction of the frame
[02:39:16 CET] <therage3> i see
[02:40:24 CET] <therage3> k so
[02:40:42 CET] <therage3> i dunno if i'm doing something wrong but i took that new vfr clip and extracted all its frames
[02:40:58 CET] <therage3> there's ~ 8000 frames....
[02:41:01 CET] <therage3> versus 1350
[02:41:09 CET] <therage3> uhm ok, am i like tripping?
[02:41:21 CET] <alexpigment> how many fingers am i holding up?
[02:41:26 CET] <therage3> lol
[02:42:04 CET] <alexpigment> i don't know man. i think bradley sort of confirmed that he doesn't know how it really works, and i think that kinda points to the fact that it doesn't really work like it's supposed to with VFR
[02:42:24 CET] <therage3> wow
[02:42:27 CET] <therage3> i just looked at the frame
[02:42:29 CET] <therage3> s
[02:42:35 CET] <therage3> there's a TON of duplicates
[02:42:41 CET] <alexpigment> last time i'll say it: set the frame rate to what you think it should be
[02:42:49 CET] <therage3> yes yes gotcha
[02:42:49 CET] <furq> if it's vfr then ffmpeg won't be extracting it properly
[02:42:51 CET] <alexpigment> and make sure it doesn't have any dupes afterward
[02:42:55 CET] <therage3> furq: oh
[02:43:01 CET] <furq> you need to do like -vsync 0 or something
[02:43:05 CET] <furq> i forget exactly what now
[02:43:15 CET] <alexpigment> oh crap, the vsync
[02:43:15 CET] <furq> it definitely shouldn't have given 8k output frames though
[02:43:22 CET] <therage3> ikr?
[02:43:27 CET] <therage3> that's why i asked, am i tripping?
[02:43:28 CET] <alexpigment> we're getting deep here, and I need to start making dinner
[02:43:32 CET] <furq> but yeah you should be able to framestep in your player
[02:43:34 CET] <therage3> because with the average frame rate
[02:43:36 CET] <therage3> and the length
[02:43:38 CET] <therage3> that did not add up
[02:43:40 CET] <therage3> the math did not work.
[02:43:41 CET] <furq> i think it's like space in vlc or something unintuitive
[02:43:49 CET] <therage3> oh jeez
[02:43:51 CET] <alexpigment> i use videoredo for framestepping fwiw
[02:43:55 CET] <furq> i just use mpv
[02:44:02 CET] <alexpigment> it's a paid program, but completely worth every single penny for what it does
[02:44:11 CET] <alexpigment> anyway, i'm off to make dinner
[02:44:12 CET] <alexpigment> later guys
[02:44:17 CET] <therage3> alexpigment: thanks for the help, enjoy
[02:47:01 CET] <therage3> yeah, sure enough, with VLC frame stepping shows next to no duplicates
[02:49:04 CET] <therage3> https://mattgadient.com/2013/06/12/a-best-settings-guide-for-handbrake-0-9-9/
[02:49:05 CET] <therage3> hmmm
[02:49:09 CET] <therage3> this guide also suggests variable
[02:50:08 CET] <furq> vfr is only useful for ivtc if it's not a consistent telecine
[02:50:18 CET] <furq> if you know for a fact that you have one then you should use cfr
[02:50:28 CET] <furq> but you'd need to framestep the entire source clip to be sure of that
[02:50:59 CET] <therage3> LOL
[02:51:08 CET] <furq> also i suspect you wouldn't be having this much difficulty if it was a clean telecine
[02:51:11 CET] <therage3> the intro alone is ~ 1350 frames
[02:51:24 CET] <therage3> furq: exactly
[02:51:29 CET] <furq> pattern changes and 30i scenes/overlays are the bane of IVTCing
[02:51:41 CET] <furq> and either of those usually means you're stuck with vfr output
[02:51:58 CET] <therage3> or also, maybe because the source material was poorly transferred from the broadcast masters to DVD, the filter is having a hard time
[02:52:04 CET] <therage3> even if the telecine is constant
[02:52:09 CET] <furq> and also dvds weren't mastered with this in mind so they're all made by idiots who hate you
[02:52:16 CET] <therage3> right, exactly
[02:52:51 CET] <furq> well -vf detelecine should've worked fine in that case because that doesn't try to do anything clever
[02:53:01 CET] <therage3> hm, that's also true o.O
[02:53:01 CET] <furq> it just combs and drops at a fixed interval
[02:53:15 CET] <therage3> i guess the telecine is variable then
[02:53:49 CET] <furq> that is often also caused by bad transfers
[02:54:48 CET] <therage3> yeah, like i said
[02:57:24 CET] <therage3> i do wish this show eventually gets released in HD
[03:33:27 CET] <zyme> Is there a specific name for those visible artifacts that are not noise - the ones that are visible line shapes that don't move that can be seen in solid colors (I'm not talking about color gradients/banding either)?
[03:33:45 CET] <DHE> like the stuff you see in jpegs?
[03:35:11 CET] <zyme> looks similar. its like in lower bitrate x264 or HEVC, but arn't blocking artifacts either.
[03:35:48 CET] <DHE> yeah h264 tends to smudge the image more than older mpegs which tended to block up more
[03:41:06 CET] <zyme> there's still more blocking artifacts even in HEVC than I would expect, especially if you kind of get your eyes to stay looking still and unfocus a bit so your attention is not on the movement - its easiest if you get up real close but from a distance you almost don't notice them without getting use to looking for it.
[03:42:28 CET] <zyme> whats the new replacement for HEVC called again - I want to say JET, but even if thats right I don't know if that'll be the offical name or if its just the dev projects name..
[03:42:47 CET] <TD-Linux> they are from intra prediction
[03:42:58 CET] <TD-Linux> JEM is the software you're thinking of
[03:44:26 CET] <zyme> thats it
[03:46:02 CET] <zyme> so is JEM going to be its name like HEVC or is it just the dev project's name? (lol)
[03:46:07 CET] <TD-Linux> h.266
[03:47:28 CET] <furq> zyme: ringing?
[03:48:47 CET] <zyme> furq: the artifacts? a lot of it does look like curved lines like parts of rings and some circular lines sometimes
[05:05:51 CET] <dr0pkick> I am trying to build ffmpeg from source on CentOS 7, everything works except a ffplay binary isn't getting generated.
[05:07:44 CET] <furq> ffplay depends on sdl2
[05:08:18 CET] <dr0pkick> I added that dependency, I read that it was quietly causing it to not build. Still isn't being generated though.
[05:08:26 CET] <furq> ffplay is also not particularly good
[05:08:33 CET] <furq> it's only really useful for debugging
[05:08:43 CET] <tdr> isnt it one of the ones you have to cd into and run make manually for?
[05:08:47 CET] <furq> no
[05:08:55 CET] <furq> at least not last time i checked
[05:09:03 CET] <tdr> lemme check my source
[05:11:05 CET] <tdr> nope
[08:21:36 CET] <illegal> https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio
[08:21:46 CET] <illegal> " When compatibility with hardware players doesn't matter then use libvorbis in a MKV container when libfdk_aac isn't available. "
[08:21:48 CET] <illegal> Why?
[09:17:33 CET] <mistym> Is there a way to access individual frames from an AVStream during *_write_header in a libavformat muxer?
[09:18:47 CET] <mistym> I'm writing a new muxer for a format which has an up-front sample table in the header.
[12:11:48 CET] <Nacht> I think that Windows 10 bash is breaking something in ffmpeg/ffprobe when you try to grab something from an url
[12:11:53 CET] <Nacht> Segmentation fault (core dumped)
[14:27:29 CET] <Bear10> does anyone know how to restream from one rtmp to another without losing quality, for whatever reason when i do ffplay and look at my rtmp stream it's perfect, when i send it to facebook it's horrible, even when my rtmp goes to my own hls server the quality is still good
[14:28:49 CET] <Bear10> i thought ffmpeg -i rtmp://.... -c:v copy -c:a copy -f flv rtmp://.... would do it
[14:28:49 CET] <BtbN> don't transcode it
[14:28:56 CET] <BtbN> Just -c copy is enough
[14:29:29 CET] <Bear10> hmm ok ill give it a shot see if it improves anything
[14:30:13 CET] <BtbN> It's the same, just less stuff
[14:30:57 CET] <Rajko> Bear10, you havent thought that facebook is recompressing for you ?
[14:31:47 CET] <Bear10> Rajko: could be, but i figured that if i went from OBS -> FB and it was good quality, and i went from OBS -> my platform -> FB it'd be the same result
[14:32:13 CET] <BtbN> It is. With -c copy it will forward the exact same bitstream. It has no impact on the quality.
[14:34:50 CET] <Bear10> ok well as long as the commands good maybe its my environment
[14:34:54 CET] <Bear10> ill test with bigger servers eventually
[14:38:39 CET] <dradakovic_> Has anyone here successfully streamed into dvbt from ffmpeg using mpegts? I am streaming a radio but it is causing me issues. I believe the UDP packets flow too fast
[14:40:30 CET] <JEEB> see the UDP protocol options and the mpegts muxer options
[14:40:40 CET] <DHE> I am streaming from ffmpeg straight into a cable plant, yes
[14:40:52 CET] <JEEB> UDP has -bitrate and MPEG-TS has -muxrate
[14:40:53 CET] <JEEB> IIRC
[14:41:08 CET] <DHE> hang on didn't I already answer this yesterday?
[14:41:24 CET] <dradakovic_> Not to me you didnt lol
[14:41:54 CET] <DHE> <dradakovic_> so input is http, converting it to mp3 and streaming it to mpegts   // could've fooled me
[14:42:28 CET] <dradakovic_> Ok but the question was different wasn't it
[14:44:07 CET] <DHE> $ ffmpeg -i [input] [codec-options] -f mpegts -muxrate 300k -bitrate 310k -pkt_size 1316 udp://239.255.255.7:23456   # a good starting point for a 256 kilobit mp3 stream
[14:44:08 CET] <dradakovic_> DHE, would you mind sharing your command here
[14:44:14 CET] <dradakovic_> thank you
[14:44:41 CET] <DHE> and do make sure you're on a recent ffmpeg. old distro versions may reject the bitrate option because they're old
[14:45:43 CET] <dradakovic_> Ok. I compiled the newest
[15:02:57 CET] <dradakovic_> I use this command which is probably similar to yours. But it is cutting when listening on our dvb equipment.
[15:02:59 CET] <dradakovic_> https://pastebin.com/V5Kv4PrN
[15:04:12 CET] <dradakovic_> We are ISP and when i compare ffmpeg radio with our enterprise radios, i can see that many more UDP packages get sent in the same period of time.
[15:04:50 CET] <dradakovic_> I also can't seem to find a good option for -muxrate as the radio simply works worse with any of my entries
[15:05:40 CET] <zyme> "kovic", that means "son of", so son of Drada?
[15:06:47 CET] <dradakovic_> Honestly, this is how my company named my laptop and hexchat took it as my nickname. Radakovic is my last name
[15:07:07 CET] <zyme> My last name is Yaskovic
[15:07:21 CET] <zyme> Translates to son of Joseph
[15:07:21 CET] <dradakovic_> Russian?
[15:07:29 CET] <zyme> Austria-Hungry
[15:08:07 CET] <dradakovic_> Cool. Now i know more about my name.
[15:09:06 CET] <JEEB> O
[15:09:28 CET] <JEEB> I've also had issues with different gear taking in UDP multicast from lavf, where I seemingly set muxrate and udp's bit rate
[15:09:43 CET] <JEEB> but I've never gotten a chance to poke at the gear that was having issues again
[15:09:44 CET] <zyme> Y's and J's looked similar in script so for some reasons a lot of J's became Y's when my family immegrated to NY.
[15:09:51 CET] <JEEB> to see how it could be debugged
[15:11:29 CET] <DHE> JEEB: the secret is to make sure you set the pkt_size to a multiple of 188 (1316 is a favourite since it maxes out as close to the 1500 MTU as possible) and use the bitrate option for UDP
[15:11:30 CET] <dradakovic_> if i set my muxrate the same as my bitrate i keep getting dts < pcr. TS is invalid. And radio plays slower
[15:11:56 CET] <DHE> modern ethernet switches are garbage and have tiny packet buffers. the pacing is more to prevent networking gear from dropping packets than the endpoint's limitations
[15:11:58 CET] <zyme> some of the older family members pronounced the Y with an accent closer to a J, lol. lots of weird spelling changes happened at ellis island back in the days.
[15:12:21 CET] <DHE> dradakovic: as I said, mpegts has overhead - at least 10%. that's why I suggested 300 kilobits for a 256k CBR stream
[15:12:32 CET] <DHE> a bit overkill, but better safe than sorry
[15:12:36 CET] <DHE> and 300 is a nice number. :)
[15:13:12 CET] <JEEB> DHE: yea I think that was set as well
[15:13:18 CET] <JEEB> @ pkt_size
[15:13:28 CET] <JEEB> but as I said, I've not been in the room with the equipment since :D
[15:13:54 CET] <DHE> JEEB: I recommend confirming with wireshark if possible. as well as dissecting the packets to see they're intact, check the time between packets to make sure it's consistent. typically a good 1/2 millisecond at least
[15:14:02 CET] <JEEB> yea
[15:14:21 CET] <JEEB> also one idea we had was to just restream another multicast from the same box
[15:14:39 CET] <dradakovic_> What if the timing is not the same. I suspect i have that issue
[15:14:42 CET] <JEEB> to first of all make sure that the box could provide a multicast that things accept
[15:15:42 CET] <DHE> it means the bitrate isn't being set correctly or your system doesn't support it (you should get an alarm though, right?)
[16:51:08 CET] <ahjolinna> hello, I tried to compile ffmpeg-full-git on arch (testing) but it currently fails to build (stable 3.4.x builds fine), build log: https://pastebin.com/raw/MjtsT4fh
[16:57:05 CET] <durandal_1707> ahjolinna: update zimg lib
[16:58:45 CET] <ahjolinna> I did update zimg to latest 2.6.3
[17:00:18 CET] <ahjolinna> (arch is still using 2.6.2, which should be the  minimum version req.)
[17:10:02 CET] <durandal_1707> ahjolinna: i guess then you need zimg master
[17:11:02 CET] <ahjolinna> I could try it, but according to this 2.6.2 is  the  minimum version req. https://github.com/FFmpeg/FFmpeg/commit/002db7d49ada290db15334b7b41fa27eb376ec5c
[17:11:54 CET] <durandal_1707> either commit is wrong or configure picks up wrong headers
[17:15:32 CET] <ahjolinna> okay that worked
[17:55:54 CET] <SortaCore> so, tune, profile, level, preset, avg/max bitrates
[17:56:03 CET] <SortaCore> which of these are used together and which can't be?
[17:56:13 CET] <alexpigment> all of them can be used together
[17:56:28 CET] <SortaCore> really?
[17:56:45 CET] <alexpigment> some of the very specifics may be overlapped and/or stomped on by other settings
[17:56:48 CET] <alexpigment> but generally speaking, you can use them all
[17:56:52 CET] <c_14> (with libx264 anyway)
[17:57:00 CET] <alexpigment> and frequently I use all of those
[17:57:26 CET] <alexpigment> if you actually want to stay within a strict set of specs, you kinda need to use most of them
[17:57:47 CET] <alexpigment> e.g. blu-ray
[17:57:59 CET] <therage3> all right
[17:58:02 CET] <therage3> time to learn some more video processing
[17:58:06 CET] Action: therage3 stretches
[17:58:17 CET] <alexpigment> :)
[17:58:56 CET] <alexpigment> SortaCore: do you have a particular underlying question that relates to this, or was it just a curiosity?
[18:06:35 CET] <dakar> hello guys
[18:06:46 CET] <therage3> hey
[18:06:50 CET] <dakar> i want to join some 10 .mov files in order to reencode them with handbrake afterwards
[18:07:09 CET] <dakar> so basically just join them with minimal processing to make it fast. handbrake will do the work later
[18:07:15 CET] <alexpigment> https://trac.ffmpeg.org/wiki/Concatenate
[18:07:17 CET] <dakar> i tried to follow the manual, but no luck
[18:07:31 CET] <alexpigment> are the videos in the same format?
[18:07:42 CET] <alexpigment> e.g. same codecs, same settings, etc?
[18:07:42 CET] <dakar> should be same-everything. they were recorded with the same device one after the other
[18:08:00 CET] <alexpigment> ok
[18:08:00 CET] <therage3> dakar: https://stackoverflow.com/questions/15908328/ffmpeg-to-combine-two-mov-files-from-iphone
[18:08:01 CET] <alexpigment> you can use the concat demuxer
[18:08:02 CET] <therage3> replace two with ten, and that should work I guess
[18:08:04 CET] <dakar> i tried this: ffmpeg.exe -i concat:"17540002.MOV|17540003.MOV" -c copy 2p3.mov
[18:08:15 CET] <dakar>  but the output file ended up being merely the 17540002.MOV
[18:08:45 CET] <dakar> i took the syntax from here https://ffmpeg.org/faq.html#How-can-I-join-video-files_003f
[18:08:58 CET] <alexpigment> yeah, it's probably because you are using MOV files
[18:09:32 CET] <dakar> i am.
[18:09:40 CET] <dakar> i dont want to mess with their encodings though, so handbrake could handle it later on
[18:09:52 CET] <dakar> (i'm not very familiar with it to pick the right settings in cli)
[18:10:03 CET] <alexpigment> well, it's worth noting that handbrake uses x264, which ffmpeg uses too
[18:10:24 CET] <therage3> dakar: i see
[18:10:24 CET] <alexpigment> but either way, you can first convert your files to mpegts
[18:10:24 CET] <dakar> like i said, im not familiar with the settings
[18:10:42 CET] <dakar> mpegts means the sources arent touched quality-wise?
[18:10:43 CET] <alexpigment> ffmpeg -i [infile] -c copy output.ts
[18:10:56 CET] <alexpigment> the -c copy means that it won't be touched quality-wise
[18:11:09 CET] <alexpigment> now i'll be the first to tell you that the mpegts muxer in ffmpeg sucks
[18:11:24 CET] <alexpigment> and so the audio will fail to be included in some cases, depending on the format of the source
[18:11:29 CET] <alexpigment> so you'll need to test this
[18:11:37 CET] <dakar> [mpegts @ 022b7020] H.264 bitstream malformed, no startcode found, use the h264_mp4toannexb bitstream filter (-bsf h264_mp4toannexb)
[18:11:52 CET] <alexpigment> ok, so add that last command in
[18:12:02 CET] <alexpigment> -bsf h264_mp4toannexb
[18:12:09 CET] <therage3> dakar: did you see my link before?
[18:12:17 CET] <therage3> dakar: it literally had that command in it that ffmpeg wants
[18:12:19 CET] <dakar> therage3 sorry, no. the stackoverflow?
[18:12:28 CET] Action: therage3 blinks
[18:12:59 CET] <therage3> ffmpeg -i input1.mp4 -c copy -bsf:v h264_mp4toannexb -f mpegts intermediate1.ts  <<< this is the first command from the accepted answer
[18:13:06 CET] <therage3> it has everything in it that you need i guess
[18:13:46 CET] <dakar> that command errors out as well. i get:
[18:13:46 CET] <dakar> Failed to open bitstream filter h264_mp4toannexb for stream 0 with codec copy: Invalid argument
[18:13:47 CET] <dakar> [mpegts @ 01d7ec60] H.264 bitstream error, startcode missing
[18:14:08 CET] <dakar> i was running: ffmpeg.exe -i 17540002.MOV -c copy -bsf:v h264_mp4toannexb -f mpegts 2.ts
[18:14:21 CET] <alexpigment> fun
[18:14:41 CET] <therage3> what's the ffprobe output for 7540002.MOV?
[18:14:49 CET] <therage3> (pastebin it, don't copy it all here)
[18:15:07 CET] <dakar> let me make sure i have the latest ffmpeg. some site suggests to make sure about that.
[18:15:12 CET] <therage3> indeed
[18:15:29 CET] <therage3> that being said, this command is from 2013
[18:15:43 CET] <therage3> so if it doesn't work because of outdated ffmpeg, your ffmpeg is woefully outdated :D
[18:15:48 CET] <alexpigment> apparently sometimes you have to map the video and audio and copy them separately
[18:15:54 CET] <alexpigment> https://trac.ffmpeg.org/ticket/2107
[18:15:58 CET] <therage3> ahhh yes
[18:16:05 CET] <therage3> the wonderful world of video processing
[18:17:21 CET] <dakar> okay i get errors with latest version as well. let me pastebin.
[18:18:07 CET] <therage3> k
[18:18:16 CET] <dakar> https://0bin.net/paste/18V57ROcjnyk0wPN#a92d-huUZHohZNSM2RHj0jw/BPgAROYlEmX+9MT9jLZ
[18:19:14 CET] <alexpigment> the specs on this video are really weird
[18:19:22 CET] <alexpigment> is this like a screen recording or something?
[18:19:34 CET] <dakar> no, it's some portable recorder for classes
[18:19:50 CET] <dakar> im not surprised it looks weird to you.
[18:20:42 CET] <therage3> this is a very bizarre format, dakar
[18:20:47 CET] <therage3> never seen anything like it
[18:20:54 CET] <therage3> hmmmmmmmm
[18:21:19 CET] <dakar> im willing to lose quality if that helps you guys help me.
[18:21:19 CET] <SortaCore> alexpigment: well, I don't know how video works, but I'm writing a transcoder
[18:21:37 CET] <SortaCore> atm I'm exposing the quality controls, so I need to know if I should warn the user if their parameters cancel out
[18:21:38 CET] <dakar> it's a class, so as long as the text on the board and the audio are good enough, it's fine for me
[18:22:42 CET] <alexpigment> dakar: well, here's the thing. you can make a temporary video that doesn't exhibit any noticable loss
[18:22:45 CET] <alexpigment> it'll be very big
[18:23:03 CET] <dakar> how big? i have 10 files that are about 1 gigabyte each.
[18:23:32 CET] <dakar> i would prefer to deal with all of them at once.
[18:23:36 CET] <therage3> that sounds suspiciously like VOB files on a DVD (the size, i mean)
[18:23:37 CET] <alexpigment> 1 sec
[18:24:00 CET] <SortaCore> one other question is how I get openh264 quality settings, does it support all of 'em
[18:24:09 CET] <dakar> ~950mb and exactly 10 minutes each. the last one is shorter and smaller.
[18:24:53 CET] <dakar> i'd like this step to be as fast as possible, even if it means larger files. handbrake is supposed to make them nicer eventually
[18:25:07 CET] <alexpigment> ok, so look at the stackoverflow link from earlier: https://stackoverflow.com/questions/15908328/ffmpeg-to-combine-two-mov-files-from-iphone
[18:25:18 CET] <alexpigment> the OP has a simple command line
[18:25:20 CET] <alexpigment> and he's trying to copy
[18:25:42 CET] <alexpigment> instead of -vcodec copy, try -crf 10
[18:25:56 CET] <alexpigment> that should force it to re-encode the video
[18:26:25 CET] <dakar> ffmpeg -i 'concat:17540002.MOV|17540003.MOV' -crf 10 -acodec copy test.mov
[18:26:25 CET] <dakar> ?
[18:27:12 CET] <dakar> not sure what this does, but it seems to be running.
[18:27:15 CET] <dakar> i imagine this will take hours?
[18:27:16 CET] <alexpigment> SortaCore: you generally don't need to worry about parameters cancelling out, assuming you're ok with ffmpeg handling that for you. one example would be preset and profile. by default, the ultrafast preset is baseline. if you specify high for your profile though, the two can't exist together. one of them stomps on the other
[18:27:51 CET] <SortaCore> alexpigment: yea, superceding is fine, but I want to be able to warn the user if that happens
[18:27:52 CET] <alexpigment> dakar: no idea how long it'll take. but crf 10 is fairly visually lossless. crf 0 is true lossless and i wouldn't really recommend that
[18:28:11 CET] <dakar> i'm okay with lossy
[18:28:21 CET] <dakar> as long as the text on the board is still fine
[18:28:37 CET] <alexpigment> SortaCore: well, it can get kinda complicated. for example, if they have a target bitrate of 100mbps for 1080p H.264 and specify level 4.1, the bitrate violates the limits of level 4.1
[18:28:37 CET] <dakar> what does this give me eventually?
[18:28:55 CET] <alexpigment> dakar: it gives you a big file in h.264
[18:29:07 CET] <alexpigment> you're just encoding now as opposed to later
[18:29:30 CET] <alexpigment> if you really want to "fine tune" it with handbrake, just let me know what your settings are there. it's very easy to match the two
[18:29:40 CET] <therage3> oh Lord
[18:29:41 CET] <dakar> i'd really like to encode later, because I'd like to reduce the size and stuff (720p instead of whatever there is now, etc.)
[18:29:41 CET] <therage3> handbrake
[18:29:48 CET] <therage3> that nightmare from yesterday
[18:29:48 CET] <therage3> jeez
[18:30:04 CET] <therage3> i pray your mov's aren't telecined or interlaced or something
[18:30:20 CET] <alexpigment> dakar: if you go to the advanced tab of handbrake, it'll say "x264 Encoder Options" at the bottom
[18:30:40 CET] <alexpigment> in ffmpeg, just put -x264-params [copied options from handbrake]
[18:31:02 CET] <dakar> cant find that.
[18:31:05 CET] <alexpigment> ok
[18:31:23 CET] <dakar> i assume CRF is the same as Constant Quality? I had it on 22
[18:31:27 CET] <alexpigment> yes
[18:31:34 CET] <dakar> the preview looked good enough.
[18:31:49 CET] <dakar> does this affect encoding time or just file size?
[18:32:00 CET] <alexpigment> crf just affects file size
[18:32:11 CET] <alexpigment> if you want the display size to be smaller, you use the -s parameter
[18:32:16 CET] <alexpigment> e.g. 960x720
[18:32:17 CET] <dakar> let me ask you something, can i do the encoding for all the .mov files in handbrake and then concat them easily?
[18:32:22 CET] <alexpigment> (since your source is 4x3)
[18:32:39 CET] <alexpigment> technically yes
[18:32:47 CET] <alexpigment> but you're making this harder/longer than it should be
[18:32:59 CET] <alexpigment> just let me know what settings you want in handbrake, and i'll give you the ffmpeg command
[18:35:28 CET] <dakar> okay so framerate untouched, CRF 25 or 22 whatever you suggest
[18:35:48 CET] <alexpigment> that's all you need?
[18:35:54 CET] <alexpigment> did you want to make it 720p or not?
[18:36:45 CET] <dakar> let me see in the preview one second
[18:37:31 CET] <dakar> resolution goes from 1728x1296 to 1280x960
[18:37:59 CET] <alexpigment> ffmpeg -i 'contact:video|video|video|etc' -s 1280x960 -crf 22 -c:a aac output.mp4
[18:38:17 CET] <alexpigment> there's obviously more fine tuning you can do, but if those are all the specs you need, that should work
[18:38:42 CET] <alexpigment> i used aac because you seemed to have concerns about size, and there's really no reason to have PCM in your video from what I gather
[18:38:53 CET] <alexpigment> (audio i mean)
[18:40:09 CET] <dakar> it's a class, so theres some noise and the speaker isnt very clear, but quality doesnt really matter
[18:40:18 CET] <alexpigment> right
[18:40:32 CET] <alexpigment> i also realize i wrote "contact" up there for some reason ;)
[18:40:33 CET] <alexpigment> but of course i meant concat
[18:40:53 CET] <dakar> gonna try :)
[18:42:30 CET] <dakar> okay it's running, probably take forever though
[18:43:27 CET] <therage3> tell me about it. yesterday i transcoded 13 episodes from a TV show, about 23 minutes each. took 12 hours
[18:43:40 CET] <dakar> i have 25 classes to go through.
[18:43:42 CET] <dakar> this is just one
[18:44:07 CET] <dakar> and this is an i7..
[18:44:24 CET] <alexpigment> well, if speed is a concern, you can add -preset veryfast
[18:44:28 CET] <dakar> what would that do?
[18:44:44 CET] <alexpigment> it would change some of the encoding parameters and make it encode faster
[18:44:59 CET] <dakar> am i going to notice those?
[18:45:14 CET] <alexpigment> generally speaking, when you encode with a faster preset, the quality suffers. but since we're specifying a constant quality value, it usually just means that the file size gets somewhat bigger to achieve the same quality
[18:45:14 CET] <bencoh> at the expense of quality (if bitrate-constrained) or size (in crf case)
[18:45:18 CET] <therage3> yes, but note that the quality will change ever so slightly, it is _not_ just a speed and filesize change as some people state
[18:45:43 CET] <therage3> the quality change may be imperceptible though
[18:45:57 CET] <therage3> (i just learned this yesterday in here...)
[18:46:05 CET] <dakar> im not very concerned about the quality, crf 22 is apparently not really best to begin with
[18:46:10 CET] <dakar> but worse than that would likely be too bad
[18:46:32 CET] <alexpigment> ok, well, the crf is up to you
[18:46:43 CET] <dakar> yeah, 22 is just fine
[18:46:48 CET] <alexpigment> but yes, if encoding time is a concern, set -preset veryfast
[18:47:09 CET] <alexpigment> (there's also ultrafast, but that sacrifices a lot to get to that speed)
[18:47:11 CET] <bencoh> anyway, veryfast is usually "acceptable" in that kind of use
[18:47:12 CET] <therage3> the general rule of thumb is, crf as high as you can stand before quality degradation makes it unacceptable, and preset as slow as you can stand
[18:47:27 CET] <bencoh> and if not, hen try faster
[18:47:31 CET] <dakar> asking again though, how bad is veryfast going to hurt the quality
[18:47:32 CET] <bencoh> then*
[18:47:41 CET] <alexpigment> dakar: you probably won't notice it
[18:48:00 CET] <therage3> dakar: i'd do a visual test with both, it'll likely be very little if anything
[18:48:20 CET] <dakar> how can i do a visual test for a few seconds of video?
[18:48:30 CET] <dakar> veryfast is 2.5 times faster
[18:48:32 CET] <alexpigment> put -t 30 in your command
[18:48:40 CET] <alexpigment> that'll make a 30 second clip
[18:48:43 CET] <therage3> if you're using handbrake, there's also a preview option
[18:48:49 CET] <alexpigment> or that
[18:49:44 CET] <dakar> ultrafast is just as good it seems
[18:49:50 CET] <dakar> but the file size is 3 times bigger than veryfast
[18:49:54 CET] <alexpigment> well, the file size will be pretty good
[18:49:55 CET] <alexpigment> yeah
[18:50:05 CET] <alexpigment> ultrafast is where size starts to become problematic
[18:50:18 CET] <alexpigment> because it's stuck using baseline profile
[18:50:27 CET] <therage3> iirc, with crf 16 and ultrafast, one file i was transcoding became _bigger than the original_ lol
[18:50:35 CET] <therage3> that's no good
[18:50:43 CET] <dakar> and apparently, for some reason, no preset is larger than veryfast (6mb vs 5mb)
[18:50:59 CET] <alexpigment> therage3: yeah, that's going to depend on the source. in his case, it sounds like the source has a really high bitrate to begin with
[18:51:22 CET] <therage3> alexpigment: yeah. mine was that &$&% cartoon :)
[18:51:32 CET] <dakar> make it grayscale :D
[18:51:38 CET] <dakar> okay i'll go with veryfast then
[18:52:05 CET] <alexpigment> therage3: right. it just comes down to how noisy/lossy the original stuff is, and its original bitrate. there are cases where crf 1 will make a much smaller file size than the original
[18:52:15 CET] <therage3> yeah
[18:52:48 CET] <therage3> alexpigment: and speaking of this, i was also going to experiment with handbrake's noise removal thingie, since this cartoon is slightly grainy in spots
[18:53:14 CET] <alexpigment> therage3: that's certainly an option. unless file size is an issue though, i wouldn't worry about it
[18:53:33 CET] <alexpigment> lack of grain sets my bs detector off, so i generally prefer not removing it
[18:54:03 CET] <dakar> out of curiosity, when ffmpeg is running it mentions bitrate, is that the bitrate of the video?
[18:54:10 CET] <alexpigment> yeah
[18:54:22 CET] <alexpigment> crf automatically determines the bitrate based on the complexity of the frames
[18:54:24 CET] <dakar> isnt 3~4k pretty high for my type of content?
[18:54:38 CET] <alexpigment> not to me, but that's what the CRF is there for
[18:54:43 CET] <dakar> also, isnt average bitrate better for this?
[18:54:49 CET] <therage3> alexpigment: you mean lack of grain indicates highly digitally processed video or something?
[18:55:01 CET] <dakar> okay, it died
[18:55:19 CET] <dakar> [h264 @ 000000ce3d5c0380] Error splitting the input into NAL units.
[18:55:19 CET] <dakar> [h264 @ 000000ce3debb1a0] Invalid NAL unit size (-472435572 > 12460).
[18:55:19 CET] <alexpigment> dakar: not usually
[18:55:19 CET] <dakar> Error while decoding stream #0:0: Invalid data found when processing input
[18:55:38 CET] <dakar> the output file is exactly 10 minutes.
[18:55:46 CET] <dakar> looks like it did one file and then died on me
[18:55:50 CET] <alexpigment> therage3: yeah. it has a distinct look that feels processed to me. i prefer to have the original grain, although file size gets bigger when preserving grain
[18:55:58 CET] <alexpigment> dakar, that's what it sounds like
[18:56:02 CET] <alexpigment> googling now
[18:56:18 CET] <dakar> i checked the files now, it is indeed just the first file
[18:56:20 CET] <therage3> alexpigment: interesting... a friend of mine also into this show noticed some digitally processed copies uploaded on YouTube and he also says they look "artificial"
[18:56:27 CET] <dakar> and it went from 950mb to 212mb
[18:56:46 CET] <alexpigment> therage3: yeah youtube's quality sucks in general, so i get that feeling from most everything i watch on yt
[18:56:58 CET] <dakar> i wonder if it would make sense to do this for all files and then mess with combining them
[18:57:24 CET] <alexpigment> dakar: possibly. still googling
[18:57:41 CET] <therage3> alexpigment: lol
[18:58:57 CET] <dakar> therage3 it sounds funny but i already a lot of time googling simply because i had no idea what to look for
[18:59:26 CET] <alexpigment> dakar: out of curiosity, is this a 32-bit ffmpeg?
[18:59:41 CET] <alexpigment> that was mentioned on one thread about this error
[18:59:41 CET] <dakar> alexpigment ffmpeg-20171204-71421f3-win64-static
[18:59:44 CET] <alexpigment> k
[18:59:48 CET] <therage3> tell me about it... and the problem with info on Google is a) people are often clueless, b) the information is scattered so you have to make it one cohesive thing
[19:00:04 CET] <therage3> we lost so much time yesterday with a detelecine thing on handbrake
[19:00:08 CET] <dakar> therage3 video encoding is one of those topics that you need to know quite a lot to handle the basics
[19:00:08 CET] <therage3> because there was weird information everywhere
[19:00:19 CET] <therage3> dakar: oh god yes, i'm learning that now
[19:00:30 CET] <therage3> yesterday was when i felt like i was getting a doctorate in this channel
[19:00:36 CET] <therage3> lol
[19:00:36 CET] <dakar> the annoying part is that im not even remotely interested in this..
[19:00:40 CET] <dakar> i just want to get something done =/
[19:01:01 CET] <alexpigment> dakar: can you see if just trying to encode video 2 causes the problem to happen?
[19:01:29 CET] <alexpigment> i'd like to know if this is the result of concatting those particular files, or if the start of video 2 is just generally bad
[19:01:33 CET] <dakar> alexpigment i just tried to process the second file on its own. i get the same error at the end.
[19:01:48 CET] <dakar> but i do get a working 10 minutes file at the end
[19:01:50 CET] <alexpigment> but it did create it successfully?
[19:01:51 CET] <alexpigment> ok
[19:02:06 CET] <alexpigment> and the source files are all 10 minutes each?
[19:02:13 CET] <dakar> except the last one of every class that's smaller
[19:02:17 CET] <alexpigment> i see
[19:03:46 CET] <alexpigment> dakar: well, i have no idea what's causing this particular error
[19:04:00 CET] <alexpigment> others here are much more knowledgeable than i am, and maybe could help
[19:04:02 CET] <dakar> any idea how to concat some files that are the output of this?
[19:04:14 CET] <alexpigment> but it sounds like you have the option to concat the results
[19:04:15 CET] <alexpigment> yes
[19:04:20 CET] <alexpigment> https://trac.ffmpeg.org/wiki/Concatenate#demuxer
[19:04:32 CET] <alexpigment> look at the section that says "using intermediate files"
[19:05:59 CET] <dakar> ffmpeg -i "concat:output2.mp4|output3.mp4" -c copy -bsf:a aac_adtstoasc 2n3.mp4
[19:06:06 CET] <alexpigment> in retrospect, if we had known that this would fail, it would have been better to make the ts in the first place
[19:06:11 CET] <dakar> this runs for 1 second, finishes without errors, creates a file that is practically bad
[19:06:14 CET] <alexpigment> yeah, that should work
[19:06:22 CET] <alexpigment> practically bad = ?
[19:07:15 CET] <dakar> identical to output2.mp4
[19:07:25 CET] <alexpigment> oh, i just noticed you're using the mp4
[19:07:33 CET] <alexpigment> did you see the section i mentioned?
[19:07:40 CET] <dakar> Using intermediate files, yes
[19:07:40 CET] <alexpigment> you need to temporarily convert to mpegts
[19:07:45 CET] <dakar> ow.
[19:07:54 CET] <alexpigment> ok, so let's rethink the gameplan here
[19:07:57 CET] <dakar> so i have to go .mov to .mp4 to .ts, then to mp4?
[19:08:03 CET] <alexpigment> you're going to go through two steps at least
[19:08:12 CET] <dakar> im fine with 2 steps as long as it works lol
[19:09:36 CET] <alexpigment> ffmpeg -i [sourcevideo] -s 1280x960 -crf 22 -c:a aac -preset veryfast -f mpegts video1.ts
[19:10:13 CET] <dakar> fwiw, the .mov to .mp4 took a few minutes, then .mp4 to .ts took a second, then concatting 2 .ts to one .mp4 took a second
[19:10:20 CET] <dakar> so it looks like a good plan
[19:10:25 CET] <alexpigment> do that for each video. at the end, just do the following: ffmpeg -f mpegts -i "concat:video1.ts|video2.ts" -c copy -bsf:a aac_adtstoasc output.mp4
[19:10:35 CET] <alexpigment> ok, so if you're fine converting the mp4 to ts, that's cool
[19:10:39 CET] <alexpigment> it's just a container swap. there's no re-encoding
[19:11:03 CET] <alexpigment> but knowing what we know now, you can simply the process as I mentioned above, by simply making the ts files first instead of the mp4 files
[19:11:10 CET] <dakar> you basically added -f mpegts to the previous thing so it gives .ts instead of mp4 eventually?
[19:11:12 CET] <alexpigment> then combining the ts files with ffmpeg afterward
[19:11:21 CET] <alexpigment> dakar: basically
[19:11:32 CET] <alexpigment> it's even implied with the output file name
[19:11:42 CET] <alexpigment> but i figured i'd specify it just in case it does something with the bitstream filters
[19:12:06 CET] <dakar> you also changed -bsf:v to -bsf:a, why?
[19:12:19 CET] <dakar> or did i miss something
[19:12:43 CET] <alexpigment> that bsf converts the aac audio from a format which is appropriate for ts to a format which is appropriate for mp4
[19:12:47 CET] <alexpigment> it's lossless
[19:13:28 CET] <dakar> okay, time to work on this then
[19:13:31 CET] <dakar> seems like i have the recepie
[19:14:00 CET] <therage3> hm
[19:14:31 CET] <therage3> i may need to remember that bsf thing later, i've often just transcoded video to mkv and stream-copied the audio
[19:14:36 CET] <SortaCore> alexpigment: should the user always specify level with profile?
[19:14:51 CET] <dakar> btw, can i simply rename .mp4 to .mkv at the end of the process? it's just a container and should work just fine, correct?
[19:15:10 CET] <alexpigment> SortaCore: most people don't. it's only needed for hardware compatibility, and in some cases, software compatibility
[19:15:33 CET] <alexpigment> dakar: yeah, if you want to set the output to .mkv, that's fine
[19:16:00 CET] <dakar> alexpigment i mean simply rename the files
[19:16:01 CET] <alexpigment> just to be clear, you're talking about renaming the output file in the command line, right?
[19:16:04 CET] <therage3> setting the output is one thing, can they just change the extension?
[19:16:07 CET] <therage3> that's what dakar is asking i think
[19:16:18 CET] <dakar> yeah im not going to redo 5 files for this ;)
[19:16:38 CET] <alexpigment> ok, so when you concat later on
[19:16:47 CET] <alexpigment> it says "output.mp4" up there in the command
[19:16:52 CET] <alexpigment> just put "output.mkv"
[19:16:59 CET] <dakar> and ffmpeg will take care of making it proper mkv?
[19:17:02 CET] <therage3> yes
[19:17:03 CET] <alexpigment> yeah
[19:17:07 CET] <dakar> awesome
[19:17:09 CET] <therage3> it will use appriopriate wrappers for the mkv container
[19:17:13 CET] <therage3> instead of mp4 container
[19:17:44 CET] <therage3> if you manually change the extension later on, maybe things like VLC could handle it because VLC just bruteforces everything and tries to play whatever it can
[19:17:48 CET] <therage3> but another player may fail
[19:17:57 CET] <dakar> okay
[19:18:52 CET] <SortaCore> so if some weirdo wants to use the level 1B
[19:18:54 CET] <SortaCore> how do
[19:19:00 CET] <alexpigment> 1B?
[19:19:08 CET] <SortaCore> yea, it's a thing
[19:19:10 CET] <alexpigment> oh, i guess that's a thing
[19:19:18 CET] <alexpigment> does -level 1b work?
[19:19:26 CET] <alexpigment> honestly, i've never used 1b ever
[19:19:44 CET] <SortaCore> even if it does, I'm doing C++, and the level is a number type @.@
[19:20:04 CET] <alexpigment> so 1b only supports a resolution of 128x96 and 30fps max
[19:20:19 CET] <alexpigment> https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels
[19:20:30 CET] <alexpigment> so that chart is invaluable
[19:20:57 CET] <alexpigment> the main things you need to look at are the max bitrate, the max resolution and corresponding frame rate
[19:21:38 CET] <alexpigment> this is why this stuff gets confusing and it's best to let ffmpeg just kinda handle it like it does
[19:23:17 CET] <alexpigment> and just to make matters more confusing, there are additional profiles (e.g. high444pp) that have different restrictions for bitrates than is listed in this chart
[19:23:28 CET] <alexpigment> the official spec has the multipliers that you can use
[19:24:15 CET] <alexpigment> (e.g. when using [whatever special profile], bitrates can be 1.5x of main profile when using level 4.1)
[19:24:33 CET] <alexpigment> that's just made up, but i remember the limits being referenced that way
[19:25:21 CET] <Rajko> is the emulation prevention byte present in also length-prefixed h264 bitstreams ? or just annex-b
[19:32:09 CET] <SortaCore> I'm sure my users will enjoy researching that
[19:36:20 CET] <alexpigment> sortacore: well, here's the thing
[19:36:26 CET] <alexpigment> 99% of people don't set a level
[19:36:53 CET] <alexpigment> people don't understand what a level is, it's effect on the resolution and bitrate, etc
[19:37:24 CET] <alexpigment> but sometimes they see something on the internet that says "high level 4.1" in supported video formats
[19:37:34 CET] <alexpigment> so you want them to be able to select that so they feel warm and fuzzy inside
[19:37:47 CET] <SortaCore> it's not just compatibility, isn't it also advanced algorithm = slower decode?
[19:37:56 CET] <SortaCore> more CPU footprint?
[19:38:12 CET] <alexpigment> maybe technically
[19:38:18 CET] <alexpigment> but it's a higher bitrate
[19:38:23 CET] <alexpigment> so probably a slower decode because of that
[19:38:39 CET] <alexpigment> and of course, slower decode due to higher resolution
[19:39:08 CET] <alexpigment> but it's like you have device A that was only rated to play 640x480 videos at a particular bitrate
[19:39:24 CET] <alexpigment> and you have device B that was rated to play 1280x720 videos at a particular bitrate and frame rate
[19:39:48 CET] <alexpigment> it's really just a way for someone to go "oh, this video should play on this device"
[19:40:12 CET] <alexpigment> it's usually a *derived* element
[19:40:28 CET] <alexpigment> the encoder sees what specs it ended up with and appends the corresponding level based on that
[19:40:40 CET] <SortaCore> looks like x264 parses 1B as 0.9
[19:41:00 CET] <alexpigment> interesting
[19:50:57 CET] <SortaCore> so does NVENC
[19:56:02 CET] <BtbN> the level setting is only ever a limit
[19:56:13 CET] <BtbN> And usually encoders will automatically set the lowest level for what they are doing
[20:04:33 CET] <AlecTaylor> hi
[20:04:52 CET] <AlecTaylor> How do I use ffmpeg to stream webcam to http:// and file? - https://superuser.com/q/1274570
[20:06:04 CET] <BtbN> you don't stream to http
[20:09:26 CET] <Rajko> BtbN, you actually can.
[20:10:15 CET] <Rajko> its used in a couple of places where you stream to "a http url" i dont remember what it actually does but i think http chunked encoding transfers are in play
[20:10:26 CET] <Rajko> i think its only viable -f flv
[20:10:48 CET] <klaxa> yes if you pass -listen 1 you can "stream" a file to _one_ client over http
[20:10:54 CET] <AlecTaylor> Rajko: Happy to switch to any codec to make this work
[20:11:00 CET] <klaxa> until the client quits of the file ends
[20:11:15 CET] <BtbN> http is just not make for video streaming. Use something more appropiate
[20:11:30 CET] <BtbN> If you absolutely must use http, generate a hls playlist and serve it via some proper http server
[20:11:35 CET] <AlecTaylor> Well how about chucking to a file, then I can serve that file as a static file in my web server, which will stream to the client right//
[20:11:36 CET] <AlecTaylor> ?
[20:11:53 CET] Action: AlecTaylor is using nginx
[20:13:03 CET] <klaxa> i think if you want to play it in a website you will need a js hls player
[20:13:19 CET] <AlecTaylor> klaxa: Doesn't the new video tags support streaming videos?
[20:13:22 CET] <AlecTaylor> *Don't
[20:15:02 CET] <klaxa> https://developer.mozilla.org/en-US/Apps/Fundamentals/Audio_and_video_delivery/Live_streaming_web_audio_and_video
[20:15:11 CET] <klaxa> doesn't look like any browser supports hls without js
[20:17:37 CET] <AlecTaylor> klaxa: Okay well happy to use a JS player then. My app is in Angular, so shouldn't be too difficult to integrate one.
[20:18:17 CET] <AlecTaylor> klaxa: So what's the command I should be using to chunk it to a file, and then I'll just use the file path from nginx? - Or is there something extra needed?
[20:18:44 CET] <klaxa> ffmpeg -i whatever [<whatever>] -f hls some/path/to/readable/webroot/master.m3u8
[20:18:45 CET] <klaxa> i think
[20:20:10 CET] <klaxa> your hls player will want the url on your webserver to the m3u8 file
[20:25:13 CET] <jfmcarreira> heyyy guys. whats is the minimum version to use the new libavcodec api?
[20:26:46 CET] <JEEB> the push/pull API?
[20:26:57 CET] <JEEB> I think it was 3.1 which was first branched after that API was added
[20:43:08 CET] <AlecTaylor> klaxa: Thanks that seems to be working
[20:57:12 CET] <zamba> when using ffmpeg -s 00:00:10.0 -i <input> -to 00:23:42.0 -c copy <output> i notice that the time counter is way off in the destination file
[20:57:17 CET] <zamba> what could be causing this?
[21:15:26 CET] <dakar> i think -s is for resolution?
[21:15:32 CET] <alexpigment> dakar: yes
[21:15:50 CET] <alexpigment> think "size" if that helps you remember it
[21:16:15 CET] <alexpigment> zamba: is the time counter correct if you omit -c copy?
[21:17:46 CET] <dakar> i was mentioning this to zamba
[21:17:53 CET] <dakar> he was using -s 00:00:10.0
[21:17:58 CET] <alexpigment> oh gotcha
[21:18:02 CET] <dakar> and said the timer was off
[21:18:09 CET] <alexpigment> -ss is what i usually use
[21:18:21 CET] <zamba> i meant -ss, yes :)
[21:18:32 CET] <alexpigment> anyway, does it cut correctly if you omit -c copy?
[21:18:32 CET] <dakar> i'm already encoding the 4th class :)
[21:18:39 CET] <alexpigment> dakar: nice :)
[21:18:43 CET] <dakar> even made a batch script to handle the errors lol
[21:18:44 CET] <zamba> alexpigment: doesn't that imply reencoding?
[21:18:57 CET] <alexpigment> zamba: yes, but it also helps identify the issue
[21:19:11 CET] <zamba> alexpigment: ah, ok
[21:19:14 CET] <alexpigment> maybe i'm wrong in this assumption, but ffmpeg probably has to cut on keyframes
[21:19:18 CET] <alexpigment> when doing it losslessly
[21:19:36 CET] <dakar> every 1h30mins becomes a nicely packed ~2gb mkv file and veryfast is doing great
[21:19:37 CET] <alexpigment> if your source has really long GOPs, then then cut could be way off
[21:20:18 CET] <alexpigment> dakar: awesome. glad that's working for you. i think there's probably an easier way to do it all still, but if you've got a batch file, then that takes away most of the complexity
[21:20:44 CET] <dakar> yeah must be better way
[21:20:59 CET] <dakar> but this works so i rather let it do its magic instead of spending time figuring a better way
[21:21:30 CET] <alexpigment> i tend to agree with that sentiment
[21:22:50 CET] <dakar> i'd usually spend the time and effort to better it, but it's a one-time mission so wth
[21:23:03 CET] <alexpigment> gotcha
[21:33:58 CET] <therage3> dakar: how is that going?
[21:55:19 CET] <dakar> therage3 smooth so far
[23:51:37 CET] <SortaCore> so the rtsp -> avframe
[23:51:42 CET] <SortaCore> can that be any pixel format?
[23:51:55 CET] <SortaCore> atm I'm getting it only as YUV420P, and for HWA I have to convert them to NV12
[23:52:11 CET] <SortaCore> but some peeps keep saying rtsp doesn't select a pixel format
[23:53:43 CET] <sfan5> rtsp is a container, it doesn't have a pixfmt by definition
[23:54:09 CET] <illegal> https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio
[23:54:11 CET] <illegal> " When compatibility with hardware players doesn't matter then use libvorbis in a MKV container when libfdk_aac isn't available. "
[23:54:30 CET] <illegal> Why?
[23:55:47 CET] <alexpigment> illegal, i think it's basically just saying that libfdk_aac is a very good aac encoder
[23:56:24 CET] <alexpigment> and that unless you need aac, you might use libvorbis if fdk_aac isn't an option (e.g. due to licensing reasons)
[23:56:42 CET] <furq> the line below that should really be merged into that line
[23:56:54 CET] <alexpigment> with that being said, i don't know how old this article is, but the built-in aac encoder in FFMPEG is very good at this point
[23:56:57 CET] <furq> yeah
[23:56:57 CET] <illegal> Correct, but I am confused as to why if hardware compatibility doesn't matter and he saying that lipopus would yield higher quality he would still basically say that you should use libfdk_aac
[23:57:01 CET] <furq> i mean it's still recommending vorbis
[23:57:11 CET] <illegal> I am not saying he is wrong or anything, I am just wondering why really
[23:57:16 CET] <furq> illegal: most things that support h264 only support aac audio in mp4
[23:57:17 CET] <illegal> seems odd
[23:57:35 CET] <furq> web browsers and apple devices, for starters
[23:57:41 CET] <alexpigment> apple for sure
[23:57:56 CET] <furq> well chrome doesn't support h264+opus in mkv
[23:58:03 CET] <furq> and idk if that's a thing yet in mp4
[23:58:20 CET] <furq> if it is then i doubt any of the browsers are that cutting edge
[23:58:23 CET] <llogan> that article is a little sloppy
[23:58:29 CET] <furq> most of the wiki is a bit sloppy
[23:58:41 CET] <alexpigment> i think it's a little out of date and doesn't really tell why it recommends x over y
[23:58:48 CET] <llogan> this one is above the slop avg
[23:58:51 CET] <alexpigment> i personally have no use for actual vorbis audio ever
[23:58:51 CET] <furq> basically use opus if you don't care about compat and fdk or aac if you do
[23:59:01 CET] <alexpigment> and opus is cool if i have some reason to use it, but i consistently never do
[23:59:02 CET] <illegal> I'll check on chrome to see if it's true, I know youtube uses opus so I don't know why chrome wouldn't support mkv+opus
[23:59:17 CET] <furq> because it doesn't support mkv
[23:59:21 CET] <illegal> ah
[23:59:38 CET] <furq> it supports vp8/9 and opus in webm or h264 and aac in mp4
[23:59:42 CET] <furq> anything else is questionable
[00:00:00 CET] --- Wed Dec  6 2017