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

[burek]

[00:13:47 CEST] <LABcrab> Hi room. I have a DVD with letterboxed 16:9. Should I import it at 720x405 or at 640x360?
[00:15:04 CEST] <c_14> I'd report it without the black bars (640x3640), but it's probably up to you
[00:15:11 CEST] <c_14> If I had the raws, I'd crop it
[00:15:29 CEST] <LABcrab> I have the VOB files.
[00:21:30 CEST] <furq> 720x405 anamorphic
[00:21:54 CEST] <LABcrab> I don't think it's anamorphic, though. Doesn't anamorphic mean that the video is 720x480 but stretches to 854x480?
[00:22:39 CEST] <furq> anamorphic in digital content generally just means non-square pixels
[00:23:04 CEST] <c_14> yeah, but if the pixels are square but  there are just black bars in the video it isn't anamorphic
[00:23:56 CEST] <c_14> And as a viewer, I find the "cropped" resolution more interesting than the one with black bars
[00:24:03 CEST] <furq> actually yeah, this just sounds badly mastered
[00:24:10 CEST] <furq> 720/405 is 1.77
[00:24:45 CEST] <furq> so it sounds like you just want to do a straight crop of this
[00:25:04 CEST] <LABcrab> Yeah. I deal with many Christian DVDs (I'm a Christian myself, I just dislike the letterboxed videos) that have the bars. Only once in a while do I see anamorphic. Unfortunately, I have an encrypted anamorphic DVD (Pure Forgiveness) that needs something like MacTheRipper.
[00:25:10 CEST] <c_14> Well, depending on input quality cropping might just make it worse
[00:25:18 CEST] <furq> if you're encoding it, i mean
[00:25:43 CEST] <furq> also obviously you'll need to go to 720x404 because the height needs to be an even number
[00:25:46 CEST] <c_14> yeah
[00:25:48 CEST] <c_14> If you are already encoding it, crop it
[00:25:51 CEST] <LABcrab> Even big studios like Warner Brothers use letterboxing.
[00:25:59 CEST] <furq> letterboxing on DVDs is usually for 2.35:1
[00:26:17 CEST] <furq> DVDs don't support that aspect ratio because of some kind of terrible decision making
[00:26:28 CEST] <LABcrab> Or Word Records (owned by Warner Music Group), to be precise.
[00:26:33 CEST] <furq> so you have to encode it with 16:9 AR plus black bars
[00:26:39 CEST] <furq> but the numbers don't add up in this case
[00:27:07 CEST] <furq> you'd end up with 2.15ish
[00:27:16 CEST] <furq> so i assume someone's just encoded 16:9 with a 4:3 AR and black bars
[00:27:21 CEST] <furq> which happens a lot with amateur stuff
[00:27:26 CEST] <LABcrab> NTSC video is 720x480. VLC plays it back at 4:3, though.
[00:27:47 CEST] <furq> yeah if it plays at 4:3 with black bars then the actual video is 16:9
[00:27:57 CEST] <furq> in which case, if you're encoding it, you just want to crop it and nothing else
[00:28:02 CEST] <LABcrab> And of lower resolution. -_-
[00:28:10 CEST] <furq> right
[00:30:12 CEST] <furq> 720x404 is fine anyway
[00:30:21 CEST] <LABcrab> Why 404 and not 405?
[00:30:31 CEST] <LABcrab> 720 / 16 * 9  = 405.
[00:30:37 CEST] <furq> the dimensions can't be odd numbers if you're using yuv420p
[00:30:47 CEST] <LABcrab> I'm using ffmpeg2theora
[00:30:49 CEST] <furq> and it's better to overcrop by 1px than have a black line at the bottom of the frame
[00:30:56 CEST] <furq> theora only supports yuv420p iirc
[00:31:11 CEST] <furq> the source is yuv420p anyway because all dvd video is
[00:31:48 CEST] <LABcrab> Yeah, but black bars mean that it's 720x480 anyway.
[00:31:57 CEST] <furq> right, but i assume you want to crop those out
[00:32:03 CEST] <furq> it's just wasted space
[00:32:11 CEST] <LABcrab> I'll take a screenshot and open it in GIMP.
[00:33:42 CEST] <LABcrab> Yeah, you're right, there's a black pixel line. I don't like the number 404. :-/
[00:34:55 CEST] <Dark-knight> alexp: thanks for your help
[00:36:26 CEST] <LABcrab> If I want two profiles (640x360 and 480x270), what is the best way to do this?
[00:41:26 CEST] <Cracki_> are you tlking about anamorphic video
[00:41:43 CEST] <Cracki_> 480 lines, usually sampled at 720 pixels/line, can be 4:3 or 16:9
[00:41:52 CEST] <LABcrab> ./ffmpeg2theora /Volumes/DVD/VIDEO_TS/VTS_09_1.VOB -vf pad=720:480:0:67 -x 640 -y 360 -a 6 -o 09_360p.ogv
[00:42:44 CEST] <LABcrab> I also added -v 6
[00:50:33 CEST] <cq1> LABcrab: Sorry, I'm jumping in and may have missed some context, but is there any particular reason you're using Ogg container and Theora?
[00:50:45 CEST] <LABcrab> For TenFourFox compatibility and to avoid MP4.
[00:51:09 CEST] <LABcrab> I mentioned that on another day, so I don't blame you if you don't know.
[00:52:10 CEST] <LABcrab> The video is 362p. >_< How can I make it 360p?
[00:52:23 CEST] <Cracki_> crop or rescale
[00:53:06 CEST] <cq1> LABcrab: Got it. Sometimes people come here and are using some weird mixture of codecs and it turns out they don't realize how much they stand to gain by using state-of-the-art formats instead.
[00:53:12 CEST] <TD-Linux> theora actually supports odd sized yuv420p
[00:53:36 CEST] <LABcrab> TD_Linux: How would I do this?
[00:53:45 CEST] <TD-Linux> just use an odd size
[00:53:55 CEST] <TD-Linux> that said... don't bother and just use 404
[00:54:07 CEST] <LABcrab> It's not 404, though, I was wrong.
[00:54:11 CEST] <TD-Linux> oh okay
[00:54:22 CEST] <LABcrab> The crop is 60 top, 58 bottom.
[00:55:42 CEST] <LABcrab> Well, I figure that scaling from 720x362 to 640x360 should be fine. What exactly happens when I scale from 362 to 360, though? Do lines get deleted?
[01:01:21 CEST] <Cracki_> no everything is resampled
[01:01:28 CEST] <Cracki_> so it's gonna get blurrier
[01:02:33 CEST] <LABcrab> This is complicated.
[01:03:56 CEST] <Cracki_> only scale if you're sure you end up with the right geometry
[01:04:15 CEST] <Cracki_> so, if you WANT square pixels, make sure after rescaling, a circle is still a circle
[01:04:36 CEST] <Cracki_> if you have rectangular pixels already, don't scale.
[01:04:46 CEST] <Cracki_> display aspect ratio is handled by players
[01:06:30 CEST] <LABcrab> I am getting a blurry bottom line just by cropping. I'm not even scaling yet. How come?
[01:06:58 CEST] <kepstin> what's the offset you're using on the crop?
[01:07:12 CEST] <LABcrab> I'd like to use 60 and 60.
[01:07:34 CEST] <kepstin> yeah, that should work fine
[01:10:57 CEST] <LABcrab> It's still giving me a blurry line of two pixels at the bottom.
[01:16:23 CEST] <kepstin> you're only cropping, right? not scaling?
[01:16:44 CEST] <kepstin> if so, then your source just has some blurry lines in it, so crop a smaller region.
[01:24:48 CEST] <LABcrab> The source seems fine.
[01:26:43 CEST] <LABcrab> It does that on all my VOB files. :-(
[01:29:05 CEST] <LABcrab> I'll send an Imgur.
[01:35:02 CEST] <LABcrab> Figured it out. VLC is glitchy.
[01:36:34 CEST] <LABcrab> The video plays just fine in Firefox.
[01:39:15 CEST] <LABcrab> Here is the right way: ./ffmpeg2theora /Volumes/DVD/VIDEO_TS/VTS_14_1.VOB --croptop 62 --cropbottom 58 -x 640 -v 6 -a 6 -o AwesomeVideo.ogv
[01:52:23 CEST] <thebombzen> why use Theora at all? :thinking:
[01:54:13 CEST] <cq1> thebombzen: See above where I asked.
[02:02:31 CEST] <LABcrab> thebombzen: For compatibility with TenFourFox and for avoiding any licensing issues with MP4. I'm not avoiding MP4 altogether, but if a file I have wasn't originally encoded in MP4 (it was from a DVD, for example), I will encode to Theora.
[02:03:16 CEST] <LABcrab> Even assuming there are no licensing issues, I would rather have Theora by default, or at the very least as an option.
[02:03:30 CEST] <LABcrab> However, if TenFourFox handles VP8 or VP9 better, I may switch.
[02:04:44 CEST] <thebombzen> cq1: I can't see from before because I hadn't joined the channel yet
[02:05:05 CEST] <TD-Linux> thebombzen, it's being decoded on slow PPCs
[02:05:28 CEST] <thebombzen> hardware compatibility would be a good reason for Theory over VP8
[02:05:47 CEST] <TD-Linux> there's no hardware decode at all on those machines.
[02:05:54 CEST] <thebombzen> Yea, but "slow PPCs"
[02:06:04 CEST] <LABcrab> So, you're telling me that Theora is better than VP8 in terms of CPU usage?
[02:06:23 CEST] <TD-Linux> generally yes, but always test
[02:06:24 CEST] <thebombzen> LABcrab: yea, Theora is computationally much simpler than VP8. Theora is derived from VP3, for reference
[02:06:40 CEST] <thebombzen> It won't be as efficient though in terms of quality per bitrate
[02:06:41 CEST] <LABcrab> On G4 and G5, there's AltiVec. On G3, there isn't. AltiVec and VP8 do well enough together, but if you say that Theora is lightweight, all the better.
[02:07:15 CEST] <LABcrab> The issue is that WordPress rejets .ogv
[02:07:30 CEST] <LABcrab> and .ogg >_<
[02:07:40 CEST] <thebombzen> WordPress probably is requiring WebM compliance
[02:07:53 CEST] <thebombzen> consider using vp8 + opus inside WebM
[02:07:56 CEST] <LABcrab> This is https://BarlowGirl.ca (not hosted by WordPress.com)
[02:08:11 CEST] <TD-Linux> you could ask the admin to add those extensions to the whitelist
[02:08:23 CEST] <LABcrab> I'm the admin. :-)
[02:08:24 CEST] <TD-Linux> (or try a vp8 version on a G3 and see if it's fast enough)
[02:08:35 CEST] <LABcrab> I see it now. "jpg jpeg png gif" etc allowed.
[02:08:45 CEST] <LABcrab> ogg and ogv are there, though.
[02:10:30 CEST] <thebombzen> how is it rejecting it?
[02:10:38 CEST] <LABcrab> "Désolé, ce type de fichier nest pas autorisé pour des raisons de sécurité."
[02:10:53 CEST] <heth> hi! I'm getting "Failed to reload playlist" as per line 1040 here: https://www.ffmpeg.org/doxygen/2.4/hls_8c_source.html when playing HLS m3u8 files that needs to be reloaded to get new chunks
[02:10:59 CEST] <thebombzen> LABcrab: "Sorry, this type of file is not allowed for security reasons."
[02:11:24 CEST] <thebombzen> You probably could guess that though cause it's so close to the English
[02:11:35 CEST] <LABcrab> Yeah. :-) I have the site bilingual.
[02:13:08 CEST] <LABcrab> Disable Real MIME Check. I'm told to use that.
[02:15:58 CEST] <LABcrab> https://BarlowGirl.ca/?p=726 is my Theora file.
[02:19:22 CEST] <farfel>  I have an mpeg ts stream stored as udp packets from packet capture; can ffmpeg extract stream from udp ? I don't want it demuxed, just extracted
[02:50:03 CEST] <LABcrab> One of my Theora files is 88 MiB. Is this fine for web streaming, or should I lower it?
[03:07:39 CEST] <thebombzen> LABcrab: it depends on the length
[03:07:44 CEST] <thebombzen> the bitrate is more important than the file size
[03:08:17 CEST] <thebombzen> it also depends on the dimensions
[03:08:34 CEST] <thebombzen> more specifically, users will expect to use bandwidth when playing videos
[03:08:42 CEST] <thebombzen> bitrate matters more than total file size
[03:13:23 CEST] <LABcrab> It is a 360p file.
[03:18:01 CEST] <LABcrab> If anyone wants to see it to find out, it's almost ready.
[03:40:14 CEST] <LABcrab> https://BarlowGirl.ca/wp-content/BigShinyPlanet/SK_Devo_360p.ogv
[03:44:35 CEST] <heth> hi! I'm getting "Failed to reload playlist" as per line 1040 here: https://www.ffmpeg.org/doxygen/2.4/hls_8c_source.html when playing HLS m3u8 files that needs to be reloaded to get new chunks
[03:48:10 CEST] <LABcrab> Playback is smooth on an iBook G4 once the video is fully loaded. Thanks for the help, everyone! :-)
[05:02:14 CEST] <alexpigment> hey guys, i've got an issue that hopefully one of you guys can help out with
[05:02:38 CEST] <alexpigment> there are certain channels (Cooking Channel) that take old SD content, then do a non-linear stretch on
[05:02:54 CEST] <alexpigment> so the middle is 4:3 and it stretches further as you get closer to the edges
[05:02:57 CEST] <alexpigment> it's fucking awful
[05:03:05 CEST] <alexpigment> anyway, is there a creative way to reverse this process?
[05:17:53 CEST] <LABcrab> I'm sorry, I wouldn't know. I've dealt with adapting a letterbox 720x480 DVD today so that the right resolution, 640x360, is used instead.
[05:19:26 CEST] <alexpigment> yeah, that's not too bad. I've done a lot of "fixing dumb resolution/aspect changes". this one though... i don't know what to do
[05:19:43 CEST] <LABcrab> Of course 854x480 > 640x360. :-)
[05:19:56 CEST] <LABcrab> Cooking Channel? Why is it in SD? Do you have an HD feed?
[05:20:04 CEST] <alexpigment> there's a "warped resize" function in avisynth, but i've never really figured out how to incorporate avisynth into my workflow
[05:20:10 CEST] <alexpigment> i have an HD feed
[05:20:23 CEST] <alexpigment> and to placate the idiots out there, they do stretching on 4:3 content
[05:20:28 CEST] <alexpigment> but it's a non-uniform stretch
[05:20:30 CEST] <LABcrab> I did ./ffmpeg2theora /Volumes/DVD/VIDEO_TS/VTS_43_1.VOB --croptop 60 --cropbottom 58 -x 640 -y 360 -v 6 -a 6 --deinterlace -o 43_360p.ogv
[05:20:33 CEST] <LABcrab> (for my task)
[05:20:55 CEST] <alexpigment> why 60 and 58, out of curiosity?
[05:21:05 CEST] <alexpigment> why not 60/60 or 62/58?
[05:21:21 CEST] <LABcrab> I'm trying to remember why.
[05:21:49 CEST] <alexpigment> mathematically, you want to actually take off 120 pixels to get from 480 to 360; anything else would cause stretching
[05:22:24 CEST] <alexpigment> obviously, sometimes the thing is not vertically centered, but the total should add up to 120
[05:22:39 CEST] <alexpigment> anyway, just my two cents on preserving the most quality
[05:23:17 CEST] <LABcrab> Actually, I used this: ./ffmpeg2theora /Volumes/DVD/VIDEO_TS/VTS_14_1.VOB --croptop 62 --cropbottom 58 -x 640 -v 6 -a 6 -o AwesomeVideo.ogv
[05:23:30 CEST] <alexpigment> ah good
[05:23:31 CEST] <LABcrab> So, I did not specify a height.
[05:23:46 CEST] <alexpigment> based on that, it should end up as exactly 640x360
[05:24:04 CEST] <LABcrab> I might have to run my script again.
[05:24:19 CEST] <alexpigment> yep, it's also worth potentially using a more optimized deinterlace
[05:24:40 CEST] <alexpigment> like for true 30i or 25i content, you want to deinterlace to 60p or 50p respectively
[05:24:46 CEST] <LABcrab> - - deinterlace right?
[05:24:50 CEST] <alexpigment> or as i do, maintain the interlacing and just use a good player
[05:25:05 CEST] <LABcrab> It's for web video.
[05:25:08 CEST] <alexpigment> i always use ffmpeg command line, so i specify yadif=1:0:0
[05:25:11 CEST] <alexpigment> yeah
[05:25:20 CEST] <LABcrab> In any event, I'd have to rerun everything another time. It took up a lot of my day.
[05:25:36 CEST] <alexpigment> in which case, either deinterlace to 60p (NTSC) or 50p (PAL), but if you know it's telecined, use an inverse telecine
[05:25:54 CEST] <LABcrab> It's NTSC. What is telecine? The video "looks" interlaced.
[05:26:08 CEST] <alexpigment> no worries, just giving you my opinions because i've learned a lot over time, and more importantly, learned what *not* to do
[05:26:45 CEST] <alexpigment> telecine is when you take 24fps (or 23.976fps) native content and conform to NTSC specs by going to 29.97 interlaced
[05:26:54 CEST] <LABcrab> Amen. I have to learn over time because it's not like I have someone showing me these things IRL.
[05:27:23 CEST] <alexpigment> in that case, you can usually go back to a perfect 23.976p signal without losing any quality via inverse telecining
[05:27:53 CEST] <furq> uh
[05:27:59 CEST] <alexpigment> i usually just gauge by the motion. is it fluid (e.g. watching the news) or is it movie-like
[05:28:33 CEST] <LABcrab> It's 29.97 according to VLC. I wouldn't know if it's telecined.
[05:28:42 CEST] <alexpigment> i sense some dissenting opinions in furq's one-word post ;)
[05:29:13 CEST] <furq> i mean that's true if you have a lossless source
[05:29:16 CEST] <alexpigment> that's fine, it's just that telecined material looks much smoother at 59.94fps progressive than 29.97fps progressive
[05:29:31 CEST] <alexpigment> quality = frame fidelity
[05:29:35 CEST] <furq> it gets less true as you lower the bitrate
[05:29:54 CEST] <furq> also you can tell if it's telecined by framestepping with deinterlacing disabled
[05:29:57 CEST] <alexpigment> you can restore the original frame fidelity. of course your bitrate changes the quality
[05:30:04 CEST] <furq> you'll have a 3-2 pattern of progressive and interlaced frames
[05:30:42 CEST] <LABcrab> Here is an example. https://barlowgirl.ca/wp-content/BigShinyPlanet/SK_Devo_360p.ogv
[05:30:45 CEST] <alexpigment> i guess i'm just used to eyeing it because it's very obvious to tell when the source is 24 vs 30i
[05:30:52 CEST] <LABcrab> I believe I did not deinterlace it. It plays well on my iBook G4.
[05:31:06 CEST] <furq> alexpigment: i mean if you have e.g. a telecined dvd source, you get cross-field artifacts
[05:31:23 CEST] <alexpigment> right, which is why you can inverse telecine to 23.976
[05:31:27 CEST] <furq> which make it harder to reconstruct the original signal
[05:31:49 CEST] <alexpigment> labcrab: i'd guess that's originally 30i material
[05:32:09 CEST] <furq> LABcrab: as a general rule, if it wasn't shot on film then it's not telecined
[05:32:12 CEST] <alexpigment> unless they went to 30p at some point in the process (which would be a noob move, but it happens even at major studios)
[05:32:31 CEST] <furq> video cameras traditionally all shoot 30i
[05:32:38 CEST] <furq> or 60i or whatever you want to call it
[05:32:50 CEST] <alexpigment> yeah, i've never figured out what to call it either
[05:32:58 CEST] <furq> and modern digital cameras will shoot progressive
[05:32:58 CEST] <alexpigment> i use them interchangeable depending on who i'm talking to
[05:33:12 CEST] <alexpigment> furq: even at major networks?
[05:33:20 CEST] <alexpigment> do they interlace from 60p to 60i?
[05:33:21 CEST] <furq> i suppose you could shoot 24p on a digital camera and then burn it to dvd or broadcast it on ntsc
[05:33:53 CEST] <furq> but you'd only do that if you had a reason to also use the 24p footage directly, for use in a theatre or something
[05:34:13 CEST] <furq> alexpigment: i have no idea, i don't work in broadcasting and i don't live in america
[05:34:23 CEST] <alexpigment> ah
[05:34:30 CEST] <furq> i don't think any networks broadcast 1080p60
[05:34:35 CEST] <alexpigment> right
[05:34:43 CEST] <alexpigment> you said all digital cameras will shoot progressive
[05:34:50 CEST] <alexpigment> which i guess i read "will" as "do" ;)
[05:34:53 CEST] <alexpigment> at any rate
[05:34:55 CEST] <furq> yeah
[05:35:00 CEST] <furq> i meant consumer stuff
[05:35:03 CEST] <alexpigment> yeah
[05:35:10 CEST] <alexpigment> i deal with mostly tv stuff
[05:35:12 CEST] <LABcrab> Over the air, it's either 1080i or 720p. 480p, one channel in my area has it as a fallback.
[05:35:18 CEST] <alexpigment> and it's all either 1080i or 720p60
[05:35:38 CEST] <furq> some stations here broadcast 1080p25
[05:35:43 CEST] <furq> or 1080i50 for sports
[05:35:44 CEST] <alexpigment> weird
[05:35:57 CEST] <furq> i know the bbc broadcasts 1080p25
[05:36:01 CEST] <alexpigment> 1080p25 seems like a bad idea to me, unless you're just showing sped-up movies
[05:36:22 CEST] <LABcrab> What happens when new codecs get launched? We have to upgrade hardware again, I suppose?
[05:36:25 CEST] <alexpigment> i get a lot of bbc rips - there's still 1080i25 content
[05:36:49 CEST] <furq> it probably also depends on the capture box used
[05:36:56 CEST] <alexpigment> LABcrab: well, a lot of new satellites in europe are already doing H.265/HEVC. they just make the consumers get new boxes
[05:37:10 CEST] <furq> yeah dvb-t2 in europe uses hevc in some countries
[05:37:12 CEST] <alexpigment> furq: well, the effective frame rate of the content is definitely 50p
[05:37:36 CEST] <alexpigment> for what it's worth, it's specifically from BBC4
[05:37:46 CEST] <furq> i assume it also depends on the camera etc
[05:37:53 CEST] <alexpigment> anyway, i'll stand by my assertion that 1080p25 broadcast is a bad idea ;)
[05:38:01 CEST] <furq> do you mean compared to 1080i50
[05:38:02 CEST] <LABcrab> I should get going soon. What do you suggest I add to my command?
[05:38:10 CEST] <alexpigment> yeah, compared to 1080i50
[05:38:16 CEST] <LABcrab> ./ffmpeg2theora /Volumes/DVD/VIDEO_TS/VTS_09_1.VOB --croptop 60 --cropbottom 58 -x 640 -y 360 -v 6 -a 6 --deinterlace -o yay.ogv
[05:38:30 CEST] <LABcrab> (I will remove -y 360 because it doesn't matter.)
[05:38:37 CEST] <alexpigment> LABcrap: honestly, this material is originally 30i, so going to 30p progressive just makes it half as smooth. there is no added judder
[05:39:04 CEST] <alexpigment> it looks fine to me unless you want to go to 60p (and most people don't do that for player compatibility reasons)
[05:39:20 CEST] <LABcrab> Is this what --deinterlace does?
[05:39:45 CEST] <furq> i don't know if anyone here remembers how to use ffmpeg2theora
[05:39:51 CEST] <alexpigment> i don't know how to use theora either
[05:39:53 CEST] <alexpigment> ;)
[05:39:55 CEST] <furq> you're probably better off just using regular ffmpeg
[05:39:57 CEST] <LABcrab> If the glove fits. :-)
[05:40:02 CEST] <alexpigment> but yes, it's ending up as 29.97p
[05:40:49 CEST] <furq> ffmpeg in.vob -vf crop=640:360:0:60,yadif -c:v libtheora -q:v 6 -c:a libvorbis -q:a 6 out.ogv
[05:40:52 CEST] <furq> i assume that does the same thing
[05:41:10 CEST] <LABcrab> I am giving this player an overhaul. https://BarlowGirl.ca/wp-content/BigShinyPlanet/BigShinyPlanet.html
[05:41:37 CEST] <LABcrab> Almost everything is letterboxed 16:9
[05:42:03 CEST] <alexpigment> yeah, if it's letterboxed 16x9 and you're going to true 16x9 640x360, that's a good plan
[05:42:11 CEST] <LABcrab> Stuff that isn't 16:9 (like the Jessie Daniels devo) will have a separate player.
[05:42:26 CEST] <furq> lol
[05:42:34 CEST] <furq> i hate to do this to you, but the first video i picked there
[05:42:39 CEST] <furq> https://barlowgirl.ca/wp-content/BigShinyPlanet/B429_TV_1.ogv
[05:42:42 CEST] <alexpigment> you could have a separate player, or you just let it fit to the 16x9 player like youtube does
[05:42:45 CEST] <furq> graphics in the bars
[05:42:49 CEST] <furq> everyone's favourite
[05:43:04 CEST] <LABcrab> Yeah, bad editing. I have a caption below for that.
[05:43:31 CEST] <alexpigment> btw, that particular video has interlacing issues. not sure if you did the same command on it
[05:43:43 CEST] <alexpigment> but it could be that the interlacing occurred somewhere earlier in the process
[05:43:48 CEST] <LABcrab> No. I have to run the command again. There are four DVDs.
[05:43:53 CEST] <alexpigment> gotcha
[05:44:03 CEST] <alexpigment> anyway, the command you have looks good to me
[05:44:15 CEST] <furq> did you try vp8 btw
[05:44:16 CEST] <LABcrab> This is fun, though. I can upload these videos at higher quality than YouTube while having good performance with Theora.
[05:44:20 CEST] <alexpigment> i'd go with x264 if you have the option, but theora will work if you have a need for it
[05:44:24 CEST] <LABcrab> VP8 doesn't play nice on PowerPC.
[05:44:31 CEST] <furq> h264/aac in mp4 is the most widely compatible
[05:44:35 CEST] <furq> i can see why you'd want to avoid it though
[05:45:15 CEST] <alexpigment> yeah, out of curiosity, is the decision to do theora just based on using your powerpc laptop?
[05:45:27 CEST] <LABcrab> It's not even "graphics in the bar", it's how some of it leaks into the 16:9 frame. >_<
[05:45:33 CEST] <alexpigment> if so, it may be worth taking one for the team and just assuming that h.264/aac will play better on everything else
[05:45:42 CEST] <furq> i'm surprised vp8 doesn't work really
[05:45:57 CEST] <LABcrab> It's based on that and other older Mac. I also want to use open source technology, and the quality is fine for the context.
[05:46:01 CEST] <alexpigment> vp8 is pretty processor intensive for a PowerPC chip, i'd think
[05:46:09 CEST] <furq> the decoder in firefox is fast and apparently one of the tenfourfox guys added altivec to libvpx
[05:46:25 CEST] <LABcrab> VP8 (in TenFourFox) has AltiVec optimizations. VP9 does too, but VP9 is slow.
[05:46:31 CEST] <alexpigment> furq: we're talking about a chip that's pre-2006
[05:46:42 CEST] <furq> if it's a laptop then maybe that makes sense
[05:46:57 CEST] <alexpigment> no hardware decoding to speak of at that point in time either
[05:46:57 CEST] <LABcrab> iBook G4 is roughly equivalent to a low-end netbook today.
[05:47:03 CEST] <LABcrab> I'm saying that loosely enough.
[05:47:12 CEST] <furq> i figured 480p would be fine considering that altivec was added to libvpx specifically for this use case
[05:47:24 CEST] <furq> but maybe a laptop cpu can't deal with it
[05:47:46 CEST] <LABcrab> Theora 480p is great on G5, a little skippy on G4.
[05:47:57 CEST] <furq> oh nice, 1.3ghz single-core
[05:48:12 CEST] <furq> my 2006 laptop is feeling pretty smug right now
[05:48:23 CEST] <alexpigment> 2006 would be intel, right?
[05:48:28 CEST] <furq> it's not a mac, so yes
[05:48:32 CEST] <furq> it's a core duo
[05:48:34 CEST] <alexpigment> core duo or core 2 duo?
[05:48:37 CEST] <furq> core duo
[05:48:37 CEST] <alexpigment> yeah, i figured
[05:48:42 CEST] <alexpigment> right after the transition
[05:48:44 CEST] <furq> i686
[05:48:47 CEST] <furq> which is annoying
[05:48:58 CEST] <furq> it does pretty well for its age though
[05:49:09 CEST] <furq> it'll play back 1080p30 avc in mpv no problems
[05:49:10 CEST] <alexpigment> furq: i gotta say, the macbook air is an amazing deal if you can find one. get 2013 or later
[05:49:28 CEST] <furq> i don't really use the laptop enough to justify having a good one
[05:49:40 CEST] <furq> especially not since i got a tablet
[05:49:42 CEST] <alexpigment> everyone is getting rid of them for retina screens, so the air doesn't resell high
[05:49:48 CEST] <alexpigment> anyway, just throwing that out there
[05:50:02 CEST] <furq> it would also break my streak of not owning any apple products
[05:50:38 CEST] <alexpigment> man, you can hate on apple all day, but their laptops are still fairly unrivaled
[05:50:48 CEST] <furq> probably
[05:51:15 CEST] <alexpigment> also, i can't watch 60p streams via any browser on my beefy windows desktop without microstutters
[05:51:16 CEST] <furq> i mean this laptop has linux, a tiling window manager, firefox with pentadactyl, vim etc
[05:51:21 CEST] <furq> so i never have to use the garbage trackpad
[05:51:22 CEST] <alexpigment> but my macbook handles it just fine
[05:51:45 CEST] <alexpigment> if you're a linux guy, i hear you
[05:51:48 CEST] <furq> i mean it's some toshiba trackpad from 2006 so it's hardly state of the art, but man
[05:51:53 CEST] <furq> no thanks
[05:52:07 CEST] <alexpigment> yeah, trackpads are largely garbage in the windows-pc world
[05:52:07 CEST] <furq> i've set everything up such that i never have to remember it exists
[05:52:15 CEST] <LABcrab> I'd want to run Linux for OBS and the many other software on there.
[05:52:48 CEST] <alexpigment> LABcrab: i've always said, if you do any real video work, you at least need a PC around
[05:52:54 CEST] <alexpigment> the linux tools are just not mature enough
[05:53:11 CEST] <furq> i wouldn't do anything on a laptop that would necessitate better screen capturing than ffmpeg and xcbgrab
[05:53:16 CEST] <furq> and i doubt i'd even need that
[05:53:17 CEST] <alexpigment> and Mac is fine if you're dealing with all in-spec stuff. Windows has a lot of little tools that handle the not-quite-to-spec stuff
[05:53:20 CEST] <LABcrab> What platform is best for OBS, though? Wouldn't Linux be best? ffmpeg is treating me well for now.
[05:53:37 CEST] <alexpigment> I'd assume Windows is best for OBS
[05:53:44 CEST] <furq> probably windows just because there's not much reason to use it otherwise
[05:53:49 CEST] <alexpigment> specially considering that hardware accelerated capture is better on windows
[05:53:56 CEST] <alexpigment> or rather, more mature
[05:53:56 CEST] <LABcrab> Okay.
[05:53:59 CEST] <furq> OBS is good if you need to hook into directx windows and stuff
[05:54:05 CEST] <furq> ffmpeg is hopeless at that
[05:54:24 CEST] <LABcrab> ffmpeg can do borders, overlays, etc. fine.
[05:54:28 CEST] <furq> and gdigrab is generally a bit crap (sorry kepstin)
[05:54:35 CEST] <furq> you probably won't be doing much gaming on linux, so if you're using x11, ffmpeg will do a perfectly good job
[05:54:52 CEST] <alexpigment> throwin shade on kepstin ;)
[05:54:58 CEST] <furq> that's fine he admits it sucks
[05:55:02 CEST] <furq> it's not his fault, it's GDI's
[05:55:05 CEST] <alexpigment> i'm just kidding anyway ;)
[05:55:38 CEST] <LABcrab> For the DVD, I should deinterlace it and remove the (optional) height, right?
[05:55:43 CEST] <alexpigment> but yeah, i think for OBS, you want to ideally capture via the GPU to free up CPU for other tasks. in which case, i'd recommend Windows with an Nvidia GPU
[05:56:00 CEST] <alexpigment> LABcrab: what you did with the first video you sent looks very good
[05:56:04 CEST] <alexpigment> you're doing the right thing
[05:56:10 CEST] <alexpigment> deinterlacing and cropping to 640x360
[05:56:42 CEST] <LABcrab> Thanks. :-) I had some help here and from looking at the web a little, so I'm glad I'm doing it right.
[05:56:50 CEST] <furq> are you sure 640*360 is right if you're cropping 118 pixels from 720*480
[05:56:56 CEST] <furq> that doesn't seem like the AR will come out right
[05:57:16 CEST] <furq> actually nvm i guess that's 16:9
[05:57:29 CEST] <alexpigment> furq: he ammended his statement
[05:57:31 CEST] <LABcrab> ./ffmpeg2theora /Volumes/DVD/VIDEO_TS/VTS_09_1.VOB --croptop 62 --cropbottom 58 -x 640 -v 6 -a 6 --deinterlace -o 09_360p.ogv
[05:57:36 CEST] <alexpigment> he's cropping 62 and 58
[05:57:37 CEST] <alexpigment> = 120
[05:57:57 CEST] <furq> yeah i meant the horizontal resolution
[05:58:08 CEST] <furq> but if it's 16:9 with borders then that's right
[05:58:18 CEST] <LABcrab> The people look "fat" at 720, but at 640, they're fine.
[05:58:19 CEST] <furq> i feel like i was already wrong about this once today
[05:58:24 CEST] <alexpigment> haha
[05:58:42 CEST] <LABcrab> I had the video in VLC for reference, and so 640 it is.
[05:58:42 CEST] <alexpigment> i mean it would be comical if it were a 16x9 dvd with pillarbox and letterbox :)
[05:59:00 CEST] <alexpigment> but no, it's just a 4x3 dvd from what i can tell. in which case, LAB is doing the right command
[05:59:00 CEST] <furq> i'm pretty sure i've seen that
[05:59:17 CEST] <furq> i used to buy a lot of real trash DVDs
[05:59:18 CEST] <alexpigment> furq: i see it on SD tv channels. it's dumb
[05:59:35 CEST] <alexpigment> furq: it sounds like it :)
[05:59:53 CEST] <furq> what's really annoying is a lot of bbc/channel 4 dvds have pillarboxing that changes in every scene
[05:59:56 CEST] <LABcrab> Well, I should get going. Thanks again for the help. See you next time. :-)
[06:00:03 CEST] <alexpigment> later LABcrab
[06:00:06 CEST] <furq> i know i complain a lot about bbc and channel 4 dvds but they are the bane of my existence
[06:00:27 CEST] <alexpigment> how does the pillarboxing change in every scene?
[06:00:39 CEST] <alexpigment> that would imply it's baked into the source
[06:01:06 CEST] <furq> it changes in every shot sometimes
[06:01:10 CEST] <furq> father ted is particularly bad for this
[06:01:18 CEST] <alexpigment> weird
[06:01:29 CEST] <alexpigment> on BBC America, they show reruns of star trek TNG
[06:01:36 CEST] <alexpigment> and it's an HD channel
[06:01:44 CEST] <alexpigment> and they definitely do letterbox + pillarbox on it
[06:02:04 CEST] <alexpigment> which just goes to show you that no one there has real-world experience with content
[06:02:51 CEST] <alexpigment> just feeding the 480i/576i 4x3 source into their 16x9 system without a thought about fixing it
[06:05:41 CEST] <furq> http://imgur.com/a/ESiXl
[06:05:47 CEST] <furq> those screenshots are one second apart
[06:06:08 CEST] <alexpigment> oh that's real common on true analog content
[06:06:15 CEST] <alexpigment> this is a pre-digital show, right?
[06:06:19 CEST] <furq> yeah
[06:06:20 CEST] <furq> 95
[06:06:24 CEST] <alexpigment> yeah, extremely commn
[06:06:27 CEST] <alexpigment> *common
[06:06:37 CEST] <alexpigment> i think it's a side effect of analog avid systems
[06:06:40 CEST] <furq> that's actually not that egregious, it was just the first example i could find
[06:06:56 CEST] <furq> there's been stuff i've ended up overcropping to like 672px wide
[06:07:05 CEST] <alexpigment> i have a huge collection of music videos from DVD and VHS sources. i just gave up cropping left and right
[06:07:30 CEST] <alexpigment> top & bottom is OK, but even then, i only crop the bottom to get rid of VHS noise
[06:07:36 CEST] <furq> it also tends to get really bad when they have external cameras
[06:07:54 CEST] <furq> it's just annoying that they wouldn't clean that stuff up for the dvd
[06:08:02 CEST] <alexpigment> yeah. trust me. this is EXTREMELY common for analog
[06:08:12 CEST] <furq> at least they left this one interlaced instead of doing a crap job of it
[06:08:13 CEST] <alexpigment> well, they probably mastered the DVD when overscan was still a thing
[06:08:24 CEST] <furq> this comes in well past the overscan region though
[06:08:30 CEST] <furq> overscan is 704 isn't it
[06:08:36 CEST] <alexpigment> no
[06:08:51 CEST] <alexpigment> 704 is the max width for analog
[06:09:09 CEST] <alexpigment> so the overscan is more in the 600s
[06:09:36 CEST] <furq> oh fun
[06:09:45 CEST] <alexpigment> the area between 704 and 704 is like the "digital blanking" area or something
[06:09:48 CEST] <alexpigment> er
[06:09:52 CEST] <alexpigment> between 704 and 720
[06:09:59 CEST] <furq> yeah i thought that was the overscan area
[06:10:15 CEST] <alexpigment> sadly not :(
[06:10:19 CEST] <furq> i'm not old enough to have experience of the horrors of analogue
[06:10:37 CEST] <furq> other than watching it
[06:10:41 CEST] <alexpigment> i have a fondness for analog, but i do know a lot about its shortcomings
[06:11:10 CEST] <alexpigment> a lot of DVDs have these alternating white noise signals at the top
[06:11:14 CEST] <alexpigment> like 2 pixels
[06:11:20 CEST] <alexpigment> but they blink rapidly
[06:11:37 CEST] <alexpigment> i think it was originally info carriers (e.g. closed captions or something)
[06:12:06 CEST] <alexpigment> but there are so many people out there making dvds that they don't all think to clean that up
[06:13:00 CEST] <alexpigment> and obviously, it's well within the overscan area, but it makes me rethink my policy of never re-encoding a dvd source
[06:13:09 CEST] <furq> i'm well beyond that point
[06:13:21 CEST] <furq> i've mentioned this before but the best thing about qtgmc is the filter for cleaning up bad deinterlacing
[06:13:30 CEST] <alexpigment> man, i need to look into that
[06:13:40 CEST] <alexpigment> i have quite a few dvds that i can't figure out what's going on with the interlacing
[06:13:41 CEST] <furq> it's properly brilliant
[06:13:57 CEST] <alexpigment> i hear only good things about it
[06:14:09 CEST] <furq> i mean the regular deinterlacer is great for sd mpeg2 stuff
[06:14:16 CEST] <furq> but the bad deinterlacer cleanup is amazing
[06:14:26 CEST] <furq> i have quite a few bbc dvds that have been really poorly deinterlaced
[06:14:30 CEST] <alexpigment> i have a good number of music video dvds where there will be combing *only* at scenecuts. and this doesn't happen on a player
[06:14:57 CEST] <alexpigment> may qtgmc is in my future
[06:15:04 CEST] <furq> including stuff that was shot in 2007 and released on dvd in 2009
[06:15:11 CEST] <furq> by which time you'd think they'd know better
[06:15:32 CEST] <alexpigment> again. lots of people making dvds out there. only some of those people know how to deal with content
[06:15:42 CEST] <furq> you'd think the bbc would know better, but apparently not
[06:16:01 CEST] <furq> on the plus side they are exactly 720*576
[06:16:05 CEST] <alexpigment> eh, i can only speak from my BBC4 Top Of The Pops rips...
[06:16:17 CEST] <furq> http://avisynth.nl/index.php/QTGMC#Progressive_Input
[06:17:00 CEST] <alexpigment> good to know
[06:17:15 CEST] <furq> that's the killer feature really
[06:17:20 CEST] <alexpigment> i need to actually just figure out how to use avisynth someday
[06:17:29 CEST] <furq> vapoursynth is better these days
[06:17:43 CEST] <furq> you really need one of the multithreaded avisynth forks to get passable speeds out of qtgmc, and those are all unstable
[06:17:49 CEST] <furq> vs has multithreading built in
[06:18:16 CEST] <alexpigment> i encoding 99.9% of everything in interlaced. if i have to wait longer for a bad interlaced video here and there, not a huge deal
[06:18:30 CEST] <alexpigment> but yeah, i'm aware of vaporsynth's existence
[06:18:44 CEST] <alexpigment> does ffmpeg support vaporsynth input?
[06:18:57 CEST] <furq> there's a tool that ships with vapoursynth which pipes out y4m
[06:19:00 CEST] <furq> you can just pipe that into ffmpeg
[06:19:09 CEST] <alexpigment> good to know
[06:19:20 CEST] <alexpigment> again, i just need to force myself to figure out how to use that
[06:20:22 CEST] <alexpigment> plus, i do deinterlace from time to time, and from everything i hear qtgmc is miles ahead of yadif for even basic bob-like deinterlacing
[06:22:51 CEST] <alexpigment> furq: i don't know if you saw my post from earlier up there, but do you know of a way to fix non-linear stretching in ffmpeg?
[06:23:11 CEST] <furq> uh
[06:23:16 CEST] <furq> that's not something i've ever encountered
[06:23:50 CEST] <furq> there's probably an avisynth filter for it though
[06:24:02 CEST] <alexpigment> i've got these episodes of Good Eats from Cooking channel that were originally 4x3 480i, but they stretched them to 16x9 with a nonlinear stretch to satisfy idiots who require that the video fills their HDTV screen
[06:24:22 CEST] <alexpigment> so the center is correct, but the edges are overstretched
[06:24:43 CEST] <furq> http://avisynth.nl/index.php/External_filters#Rotation.2FShear.2FSkew.2FPerspective
[06:24:46 CEST] <furq> maybe one of those?
[06:25:00 CEST] <furq> you could probably do it with geq in ffmpeg but that's really slow
[06:25:35 CEST] <alexpigment> https://forum.videohelp.com/threads/356521-Convert-non-linear-stretched-16x9-HDTV-video-back-to-4x3-HDTV#post2245857
[06:25:45 CEST] <alexpigment> they recommend WarpedResize
[06:25:57 CEST] <alexpigment> i was really hoping for something native in ffmpeg
[06:26:05 CEST] <alexpigment> i'll look into geq
[06:26:13 CEST] <furq> geq will be incredibly complicated
[06:26:33 CEST] <furq> doesn't look like there's a vs port of warpedresize
[06:27:21 CEST] <alexpigment> oh well
[06:27:27 CEST] <alexpigment> this isn't mission critical really
[06:27:46 CEST] <alexpigment> i was just hoping to replace some old xvid tvrips with some pure DTV rips
[06:28:07 CEST] <alexpigment> i hate ripping groups and the decisions they make, so i always try to get my own copy
[06:28:36 CEST] <alexpigment> it's just the penalty of working in the video world and not being able to turn off that quality-hyper-sensitive part of my brain i guess :)
[06:34:11 CEST] <alexpigment> aight, bed time. later furq
[06:54:33 CEST] <durandal_1707> one could use perspective filter, but thats too hard for furq to grasp
[08:36:48 CEST] <cbsrobot> CAn someone explain why the following happes? When I amerge 8 mono files to a 8 channel audio file and mux it to aac the last channel will get a filter applied.
[08:36:54 CEST] <cbsrobot> see https://transfer.sh/7ilvS/Screen%20Shot%202017-08-03%20at%2008.29.21.png
[08:37:23 CEST] <cbsrobot> left side aac, right side wav
[08:46:24 CEST] <cbsrobot> ah probably i can set the -cutoff option ....
[08:48:04 CEST] <atomnuker> cbsrobot: probably the layout maybe
[08:48:24 CEST] <atomnuker> if the last channel is marked as lfe
[08:48:44 CEST] <cbsrobot> atomnuker: the cutoff is not the solution
[08:50:01 CEST] <cbsrobot> but how do I mux  8 discreet channels not applying any postprocessing but still set the channel layout to 7.1 ?
[08:53:40 CEST] <atomnuker> dunno
[08:54:52 CEST] <Nacht> I take it you've read this ? https://trac.ffmpeg.org/wiki/AudioChannelManipulation
[08:55:29 CEST] <cbsrobot> seems libfdk_aac(enc) honors the cutoff option while the aac(enc) does not ...
[08:55:52 CEST] <cbsrobot> Nacht: yeah - not all but most
[08:56:33 CEST] <atomnuker> cbsrobot: no, aac will honor the cutoff option
[08:57:07 CEST] <atomnuker> cbsrobot: oh, wait, the filtering happens due to the encoder
[08:57:15 CEST] <cbsrobot> atomnuker: cant find it in https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/aacenc.c
[08:57:20 CEST] <atomnuker> if a channel is marked as LFE it'll be lowpassed
[08:57:25 CEST] <cbsrobot> but it's in https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libfdk-aacenc.c
[08:57:28 CEST] <atomnuker> this is specified by AAC
[08:57:36 CEST] <cbsrobot> ah gosh
[08:57:43 CEST] <atomnuker> so you can't have an LFE channel which isn't lowpassed
[08:57:47 CEST] <cbsrobot> there is no way to avoid this ?
[08:58:14 CEST] <atomnuker> nope, its specified by AAC, if the layout has an LFE channel it'll be lowpassed
[08:58:34 CEST] <cbsrobot> atomnuker: thanks - time to try opus :-)
[08:58:34 CEST] <Nacht> libfaac.c does support it
[08:58:49 CEST] <cbsrobot> I guess the cutoff is used for all channels
[08:58:57 CEST] <cbsrobot> not only lfe
[08:59:00 CEST] <atomnuker> yes, its used for all channels of course
[09:00:24 CEST] <atomnuker> cbsrobot: opus still seems like it'll do special things to a channel if its marked as LFE
[09:00:39 CEST] <atomnuker> select a layout which does _not_ have an lfe channel and it'll all work
[09:01:44 CEST] <cbsrobot> hmm whats the default container for opus ? is it opus ?
[09:01:54 CEST] <atomnuker> "octagonal" seems what you have
[09:02:27 CEST] <atomnuker> though if the layout is 7.1 where one channel is LFE it'll be incorrect
[09:03:04 CEST] <cbsrobot> well - actually it's not
[09:03:30 CEST] <cbsrobot> but I was wondering why that happens anyway
[09:03:39 CEST] <atomnuker> ok, I thought you were being stupid for not wanting an actual LFE channel to be treated differently than an LFE channel
[09:06:12 CEST] <cbsrobot> seems setting -channel_layout octagonal will not cripple the last channel
[09:06:27 CEST] <cbsrobot> ah wait
[09:08:32 CEST] <cbsrobot> no - at least not for aacenc
[09:09:12 CEST] <cbsrobot> and libfdk_aac won't allow octagonal layout
[09:09:49 CEST] <cbsrobot> and opus is lie: [libopus @ 0x7fe392074200] Invalid channel layout octagonal for specified mapping family -1.
[09:09:54 CEST] <cbsrobot> *like
[09:11:35 CEST] <atomnuker> cbsrobot: try -mapping_family 255
[09:11:44 CEST] <cbsrobot> for opus ?
[09:11:47 CEST] <atomnuker> yes
[09:12:01 CEST] <atomnuker> aacenc doesn't support non-standard layouts
[09:12:04 CEST] <cbsrobot> does audacity support opus yet ... ?
[09:12:38 CEST] <cbsrobot> seems not
[09:13:15 CEST] <cbsrobot> well aacenc allows me to set -channel_layout octagonal on the command line, but the last channel gets treated as LFE
[09:13:54 CEST] <atomnuker> yes, it thinks its 7.1 instead, it only uses the channel count
[09:14:26 CEST] <atomnuker> supporting non-standard layouts in aac is difficult, confusing and practically guaranteed to not decode with the correct layout
[09:16:02 CEST] <atomnuker> opus with -mapping_family 255 seems to work here
[09:16:13 CEST] <atomnuker> (with octagonal layout)
[09:17:10 CEST] <cbsrobot> atomnuker: I'm figuring out the showwavespic options .... because audacity cannot open it
[09:20:14 CEST] <cbsrobot> atomnuker: yeah that seems to work
[09:20:15 CEST] <atomnuker> -filter_complex showspectrumpic=split_channels=yes
[09:20:19 CEST] <cbsrobot> thanks a lot
[09:21:11 CEST] <cbsrobot> I used showwavespic=s=1024x960:split_channels=1
[09:24:12 CEST] <cbsrobot> guess it's showspectrumpic=mode=separate
[10:35:55 CEST] <Ajey> Hi folks, I was wondering is there a way in FFMPEG where it only uses hardware to decode h264? Basically I do not want to use software decode (even as a fallback).
[10:36:19 CEST] <Ajey> It should always use the hardware for decode. How do I achieve this. Any pointers would be helpful :)
[10:41:07 CEST] <Nacht> For encoding you mean I take it ?
[10:42:14 CEST] <Nacht> Here some info regarding it: https://trac.ffmpeg.org/wiki/HWAccelIntro
[10:43:05 CEST] <dystopia_> when i tested hardware decoding and software encoding, the diffrence was negligible
[12:03:56 CEST] <nyuszika7h> I have some problematic .mkv files, if I make a copy with -ss greater than 2 seconds, some metadata like x264 encoding settings are lost
[12:04:34 CEST] <nyuszika7h> also when remuxing with mkvtoolnix it strips them completely, which it normally doesn't - but then I realized it's not an mkvtoolnix regression, something is wrong with the files
[12:04:43 CEST] <nyuszika7h> is there any way to "fix" them?
[12:06:30 CEST] <nyuszika7h> oh wait it also only happens with mkvtoolnix if I strip the first 2 seconds
[12:07:06 CEST] <nyuszika7h> ok looks like remuxing them with mkvtoolnix as-is fixes it
[12:33:11 CEST] <damdai> what is better?  ATI Radeon HD 5850  or  geforce gt 1030
[14:34:35 CEST] <kepstin> furq: alexpigment well, yeah, the idea behind getting the gdigrab stuff in was just to have *something* that works on basically all windows systems.
[14:36:38 CEST] <kepstin> I use it as part of a screen sharing application for the educational market, people do things like spreadsheets and quick demos there, not games.
[16:20:42 CEST] <Mista-D> While encoding X264 to MP4, what is the method to set "fixed_frame_rate_flag" to 1 please?
[16:28:57 CEST] <jkqxz> Mista-D:  -x264opts force-cfr=1
[16:29:15 CEST] <jkqxz> (And make sure your input really is CFR.)
[16:32:28 CEST] Action: JEEB would recommend x264-params instead of x264opts
[16:33:14 CEST] <Mista-D> Thanks. -x264-params force_cfr=1:...
[16:33:16 CEST] <jkqxz> Yes, I should too.  Sorry.
[17:19:44 CEST] <thebombzen_> Out of curiosity, who is the Arch Linux downstream maintainer for ffmpeg?
[17:55:12 CEST] <jya> high, how do you get ffmpeg to produce fragmented mp4 with base-data-offset-present not set?
[17:55:29 CEST] <jya> right now it's always set, which makes it non compliant to ISOBMFF for using with Media Source Extension
[19:05:02 CEST] <Dark-knight> hello
[19:05:20 CEST] <Dark-knight> is anyone busy helping someone?
[19:05:28 CEST] <Dark-knight> not*
[19:06:47 CEST] <Dark-knight> I'd like to create a .bat file that converts all the mkv files in a folder to mp4 in one click, while keeping the same file names for each.
[19:07:18 CEST] <Blubberbub_> the ffmpeg part of this is probably easier than the bat-part... granted you already have ffmpeg installed...
[19:07:56 CEST] <Dark-knight> the bat file is simply for my own ability to reuse this at a later date without having to remember anything
[19:11:27 CEST] <furq> are these mkvs all mp4 compatible
[19:11:34 CEST] <Dark-knight> I believe so
[19:12:13 CEST] <Dark-knight> AVC video and AAC audio
[19:12:49 CEST] <Dark-knight> I have about 50 mkvs
[19:12:57 CEST] <furq> http://vpaste.net/1btIJ
[19:13:00 CEST] <furq> something like that then
[19:13:16 CEST] <Dark-knight> hmm
[19:13:25 CEST] <Dark-knight> I don't quite understand it, but thank you
[19:14:00 CEST] <furq> i tend to install msys on windows systems so i don't ever have to deal with batch
[19:14:01 CEST] <Dark-knight> so I just put that in a .bat file and put it in the "bin" folder, along with all the files right?
[19:14:09 CEST] <furq> right
[19:14:42 CEST] <Dark-knight> its a shame I can't figure out how to get the bat file to work anywhere outside the bin folder
[19:15:26 CEST] <Dark-knight> quick question
[19:15:42 CEST] <Dark-knight> is the -map necessary?
[19:16:16 CEST] <furq> maybe
[19:16:20 CEST] <furq> -map 0 will keep every stream
[19:16:29 CEST] <furq> if you omit it then the outputs will all have one audio and one video stream
[19:16:57 CEST] <Dark-knight> I have a .bat file that converts single file mkvs to mp4s and it doesn't use -map
[19:17:07 CEST] <Dark-knight> should I add -map to it then?
[19:17:25 CEST] <Dark-knight> it doesn't matter if there is only 1 stream for each right?
[19:17:39 CEST] <furq> not really but there's no harm in keeping it
[19:18:02 CEST] <Dark-knight> it only matters if there are multiple audio or sub streams right?
[19:19:46 CEST] <Dark-knight> what does adding the n to "%%~nf" do?
[19:20:24 CEST] <JEEB> batch script thing, look up batch scripting
[19:20:26 CEST] <Blubberbub_> i think that removes the file extension from whatever is in %f
[19:21:18 CEST] <Dark-knight> furq: you mentioned msys?
[19:25:19 CEST] <Dark-knight> anyway thanks for the help
[19:38:40 CEST] <Mockarutan> So I'm trying to understand the frame_size (FR) in audio codec better (Opus and Vrobis). When opening Opus, the FR is 960, when opening Vorbis it's 64. My frames are 1024. Is swr_convert suppose to solve both by itself?
[19:50:10 CEST] <durandal_1707> no
[20:03:24 CEST] <durandal_1707> there is code in lavu though
[20:05:07 CEST] <Mockarutan> Not familiar with lavu? libvautil or what?
[20:05:40 CEST] <Mockarutan> libavutil*
[20:06:00 CEST] <durandal_1707> yes
[20:26:14 CEST] <Mockarutan> Hmm, can you point me to any specific functions?
[20:26:51 CEST] <durandal_1707> fifo or something like that
[20:45:26 CEST] <rpw> I'm building ffmpeg from source on a ububtu16.04 VM.  Getting this error during configure.     "cuda_sdk not found"
[20:46:08 CEST] <rpw> cuda_sdk is installed in /usr/local with softlink /usr/local/cuda  to v8.0
[20:46:25 CEST] <BtbN> well, something it needs is missing
[20:46:30 CEST] <BtbN> check the config.log and fix it
[20:47:03 CEST] <BtbN> But do you really need the cuda_sdk parts?
[20:47:07 CEST] <BtbN> It's fairly minimal so far
[20:47:09 CEST] <rpw> i do
[20:47:16 CEST] <rpw> I'll check the log. please standby
[20:47:20 CEST] <BtbN> For what?
[20:47:27 CEST] <BtbN> The only thing it enables is scale_cuda.
[20:47:46 CEST] <rpw> i'm using that actually haha
[20:57:36 CEST] <rpw> gcc -L/usr/local/cuda/lib64
[20:57:46 CEST] <rpw> /usr/bin/ld: cannot find -lcuda
[20:57:48 CEST] <rpw> collect2: error: ld returned 1 exit status
[20:57:49 CEST] <rpw> ERROR: cuda_sdk not found
[20:58:33 CEST] <JEEB> as root, `find / -iname '*cuda*.so'`
[20:58:37 CEST] <JEEB> (that will take a while)
[20:59:41 CEST] <rpw> /usr/local/cuda-8.0/targets/x86_64-linux/lib/stubs/libcuda.so
[20:59:43 CEST] <rpw> /usr/local/cuda-8.0/targets/x86_64-linux/lib/libcudart.so
[20:59:53 CEST] <BtbN> libcuda.so is part of the nvidia driver
[20:59:54 CEST] <BtbN> not the SDK
[21:00:11 CEST] <JEEB> ^that's it
[21:00:25 CEST] <rpw> so I just need to provide that library path to the linker?
[21:00:34 CEST] <BtbN> you need to install the nvidia driver
[21:00:53 CEST] <rpw> can that be done on a virtual box?
[21:00:59 CEST] <JEEB> why not?
[21:01:08 CEST] <JEEB> it's not like you need to *load* it :P
[21:01:18 CEST] <JEEB> although isn't that stuff nonfree so you can't distribute that binary
[21:01:39 CEST] <BtbN> if you just want to build it, you can as well just copy that stub library to somewhere in your search path
[21:01:42 CEST] <BtbN> that's what it's there for
[21:01:52 CEST] <JEEB> ok if the stuff works
[21:01:54 CEST] <rpw> just want to build it for testing
[21:02:06 CEST] <JEEB> then -L/usr/local/cuda-8.0/targets/x86_64-linux/lib/stubs/ into extra ldflags
[21:02:16 CEST] <rpw> as for installing the driver, does it matter which version I install?
[21:04:21 CEST] <rpw> thanks guys! that worked!
[21:04:26 CEST] <rpw> you're awesome
[21:17:29 CEST] <MacITguy> Hello, Im trying to create a video mosaic from multiple synced videos that are of 35GB each, which is working fine, as long as Im processing the entire length of the sources. Id like to create the mosaic from a trimmed version of the sources, without duplicating content. For that I use the -ss and -to parameters, but I was only able to apply them to the output, so there is a long seek time before the encoding starts. Can -ss and -to be applied to 
[21:17:30 CEST] <MacITguy> of the sources in order to shorten the seek time? Thanks in advance
[21:21:51 CEST] <pgorley> hi, vp8_mediacodec doesn't seem to work on my armv7 (cortex-a7, mali-400 mp)
[21:22:35 CEST] <pgorley> on vlc ACodec's onOutputBufferDrained is called every time onInputBufferFilled is called, but with FFmpeg, it's never called
[21:26:13 CEST] <pgorley> is this a known bug?
[21:26:13 CEST] <pgorley> also, for FFmpeg, onInputBufferFilled prints a negative timestamp, whereas with VLC it's a positive timestamp
[21:34:03 CEST] <m3e33> Hey everyone. Is it possible to take a rtmp stream and convert it in to a ffm stream?
[21:35:51 CEST] <m3e33> I tried doing ffmpeg -i rtmp://localhost:1935/live http://localhost:9609/feed1.ffm    and it doesnt work :(
[21:36:27 CEST] <BrightScripters> Would anyone care to help? Here is the command line: ffmpeg  -n -v error -report  -an  -i '3.mp4'  -i '4.mp4'  -i '5.mp4'   -ss 00:07:06.000  -to 00:10:27.000 \
[21:36:28 CEST] <BrightScripters> -filter_complex "color=c=purple:size=3840x2160 [base]; \
[21:36:29 CEST] <BrightScripters>  [0:v] crop=819:1456:3276:424, transpose=1, setpts=PTS-STARTPTS, scale=1920x1080 [upperleft]; \
[21:36:31 CEST] <BrightScripters>  [1:v] crop=819:1456:3276:424, transpose=1, setpts=PTS-STARTPTS, scale=1920x1080 [lowerleft]; \
[21:36:32 CEST] <BrightScripters>  [2:v] crop=819:1456:3276:424, transpose=1, setpts=PTS-STARTPTS, scale=1920x1080 [upperright]; \
[21:36:34 CEST] <BrightScripters>  [base][upperleft] overlay=shortest=1 [tmp1]; \
[21:36:35 CEST] <BrightScripters>  [tmp1][upperright] overlay=shortest=1:x=1920 [tmp2]; \
[21:36:37 CEST] <BrightScripters>  [tmp2][lowerleft] overlay=shortest=1:y=1080\
[21:36:38 CEST] <BrightScripters> " -c:v libx265 -x265-params bitrate=25000:vbv-bufsize=8000:vbv-maxrate=40000 -pix_fmt yuv420p -r 29.97  'Player_6.mp4'
[21:36:52 CEST] <BrightScripters> Sorry for the multiple lines
[21:41:17 CEST] <owenthewizard> hey guys, is anyone here experienced with ffserver?
[21:41:31 CEST] <owenthewizard> I'm trying to stream video from the camera on my Raspberry Pi
[21:41:44 CEST] <owenthewizard> I setup my ffserver config like so: https://pastebin.com/fc5swATk
[21:42:18 CEST] <owenthewizard> I just need to get the correct ffmpeg command to send video
[21:42:59 CEST] <owenthewizard> I have the h264_omx encoder and the h264_mmal decoder enabled, if that helps
[21:44:55 CEST] <owenthewizard> When i do `ffmpeg -f v4l2 -i /dev/video0 -f ffm -vcodec h264_omx http://localhost:8090/feed1.ffm` I get a 404 not found
[21:45:54 CEST] <Trevor__> Hi!  Why is this not working for me? "ffmpeg -r 30 -i D:/BeginningIntro%04d.tif streamintro.mp4"  the file names are formatted BeginningIntro0000.tif....
[21:48:51 CEST] <BtbN> ffserver is dead, don't use it.
[21:49:58 CEST] <owenthewizard> Oh, this is news to me!
[21:51:19 CEST] <JEEB> people keep trying to keep it in the tree but you're highly unlikely to get any support for it
[21:51:31 CEST] <JEEB> you generally want to use ffmpeg.c with some media server
[21:51:31 CEST] <BtbN> it's only kept alive by some people blocking its removal, but nobody of them actually maintains it
[21:51:57 CEST] <BtbN> The only fixes it got lately have been related to keep it working at all, no bug fixes, nothing
[21:53:29 CEST] <Trevor__> Hi! why is ffmpeg not finding the file? "ffmpeg -r 30 -i D:/BeginningIntro%04d.tif streamintro.mp4"  is what I type in, the file names are formatted BeginningIntro0000.tif, BeginningIntro0001.tiff, .... and the folder is in D:/
[21:55:16 CEST] <Trevor__> nevermind, didn't specify the folder, then the files
[21:55:23 CEST] <Trevor__> <3 you guys
[21:55:49 CEST] <BrightScripters> Trevor__: you have a character in the file name that is not helping& %04
[21:57:53 CEST] <Trevor__> Oh, just %04?
[22:01:14 CEST] <BrightScripters> Trevor__: you could try and rename the file so it has letters, numbers, -_ and nothing else. No spaces
[22:32:35 CEST] <pgorley> does ffmpeg support packet loss concealment for opus?
[22:50:53 CEST] <goiko> hi, i am working on a project that uses ffmpeg: https://pitube.github.io/ - feedback welcome! #pitube - pre-alpha version - thanks =)
[23:28:43 CEST] <vincentjames501> Just out of curiosity, why does the absence of the `--enable-nonfree` compilation flag include encoders/decoders that are clearly not free such as H.264?
[23:36:28 CEST] <jkqxz> vincentjames501:  The freedom being considered there is the ability to distribute what gets built.  Any licences which might be required to actually run it in specific countries is not relevant to that.
[23:38:33 CEST] <furq> vincentjames501: nonfree in this case specifically refers to lgpl compatibility
[23:40:21 CEST] <alexpigment> oh weird. i was under the impression that "nonfree" had to do with the fraunhofer aac encoder
[23:40:35 CEST] <alexpigment> i guess i'm just used to my build script asking me about non-free codecs
[23:40:44 CEST] <alexpigment> and it specifically mentions that one (and only that one)
[23:41:07 CEST] <furq> fdk is gpl incompatible
[23:41:15 CEST] <alexpigment> right
[23:41:16 CEST] <furq> there's some stupid fraunhofer clause in the license that makes it nonfree
[23:41:16 CEST] <alexpigment> which is fine
[23:42:06 CEST] <alexpigment> i'm just saying that i thought nonfree referred to that, and "enable-gpl" was more related to distrubiting non-lgpl encoders
[23:42:21 CEST] <alexpigment> i didn't realize nonfree also dealt with lgpl/gpl licensing stuff
[23:43:22 CEST] <vincentjames501> We want to use FFmpeg in our application to convert a few different audio formats to pcm_mulaw (Opus, Vorbis, MP3, and other free codecs). We will be invoking the FFmpeg binary as a separate process. We will never distribute the FFmpeg binary as it's just server side when users upload audio files. Our application will also reject and never convert non-free codecs, are we fine to use the FFmpeg binary
[23:43:23 CEST] <vincentjames501>  distributed on the ffmpeg site? We can deal with the GPL restrictions.
[23:43:28 CEST] <jkqxz> --enable-nonfree essentially implies --enable-gpl, because if you can't distribute something at all then you are certainly going to be able to conform to the GPL's requirements on you if you do distribute it.
[23:43:45 CEST] <furq> vincentjames501: if you're not distributing binaries, you don't have to comply with the gpl
[23:44:02 CEST] <furq> with that said, it sounds like you don't actually need nonfree
[23:44:12 CEST] <furq> the builtin decoders are all lgpl
[23:44:51 CEST] <vincentjames501> furq, can my company get in trouble just because the FFmpeg binary CAN encode H.264 for example even if we don't use it?
[23:44:52 CEST] <jkqxz> You do have to comply with the GPL, but it imposes no restrictions on you whatsoever if you don't distribute it.  That's not quite the same as saying you don't have to comply with it :)
[23:44:55 CEST] <alexpigment> vincentjames501: you're actually in the best case scenario for not having to worry ;)
[23:45:20 CEST] <furq> vincentjames501: i very much doubt it
[23:45:55 CEST] <furq> you'd probably be most likely to get in trouble for decoding patented audio codecs
[23:46:08 CEST] <alexpigment> dolby used to be a big stickler about that
[23:46:14 CEST] <furq> but that stuff only really applies if you're making money within the US
[23:46:15 CEST] <alexpigment> but their ac3 patents expired
[23:46:42 CEST] <furq> and we never heard from them again
[23:46:44 CEST] <furq> oh wait
[23:47:32 CEST] <furq> but yeah if your product decodes patented audio codecs then you should probably look into licensing it
[23:47:33 CEST] <alexpigment> no i'm just talking about having an application that makes money and decodes ac3. they were very diligent about C&D notices
[23:47:36 CEST] <DHE> vincentjames501: enable-gpl and enable-nonfree are about licenses. as everyone's said, if you keep the libraries and binaries private then you can do anything you want. I'm using x264 (gpl) + libfdk_aac (non-free) here. I just can't give you my EXE
[23:48:11 CEST] <jkqxz> vincentjames501:  If you have some specific reason to be worried about that then you can disable codecs you don't want to include at configure time.
[23:48:22 CEST] <furq> vincentjames501: you still technically need a license if the product/service is free, but it's unlikely anyone will ever bother coming after you
[23:50:35 CEST] <furq> i'm not really sure how licensing would work for a web service
[23:50:50 CEST] <furq> aac has a flat per-unit charge and nothing else afaik
[23:51:24 CEST] <vincentjames501> furq, our product is not free, but audio encoding isn't at all what we do. We also only plan on supporting Opus, Vorbis, MP3, and other free codecs.
[23:51:35 CEST] <furq> well you're only encoding to ulaw so that bit is fine
[23:51:46 CEST] <furq> but you'd still need a license for decoding aac
[23:52:20 CEST] <vincentjames501> Ok, if we don't ever decode aac (aka we reject the user upload), are we still on the hook then?
[23:52:26 CEST] <furq> probably not
[23:52:34 CEST] <vincentjames501> Assuming the binary is "capable" of doing it
[23:52:47 CEST] <furq> i mean you can remove the patented codecs from your ffmpeg binary if you're paranoid
[23:53:13 CEST] <vincentjames501> I'm just trying to avoid a complex compilation command, having to compile it for a bunch of different environments, updates, etc
[23:53:14 CEST] <furq> but there's not really any way for via corp or whoever to know that you're selling a service that uses a binary that's capable of decoding aac
[23:53:32 CEST] <vincentjames501> I agree furq, just being overly paranoid
[23:53:45 CEST] <furq> well yeah it's not that complicated to disable decoders
[23:54:11 CEST] <furq> aac is a very popular codec though so it might be worth looking into licensing it
[23:54:55 CEST] <vincentjames501> Yeah, we may if users actually request it.
[23:55:15 CEST] <furq> it's 0.98 USD "per unit", whatever that means for a web service
[00:00:00 CEST] --- Fri Aug  4 2017