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

[burek]

[00:00:38 CET] <therage3> but for NTSC regions as well?
[00:00:43 CET] <alexpigment> upsampling from 44.1 to 48 hasn't ever been that noticeable to me, and i've done it with various degrees of professional tools
[00:00:58 CET] <therage3> because if that's the case, I don't follow what problem ChocolateArmpits is even having, if that's a standard format
[00:01:17 CET] <therage3> it depends on what program/algorithm you use. Sox has a very good resampler so it may not be that bad
[00:01:20 CET] <ChocolateArmpits> therage3, it's specifically for NTSC rates
[00:01:38 CET] <therage3> but low-CPU intensive algorithms that employ linear interpolation may sound like ass
[00:01:45 CET] <ChocolateArmpits> Other rates like 25p or 24000/1001 have equal number of samples per frame
[00:02:14 CET] <therage3> ChocolateArmpits I see
[00:02:41 CET] <ChocolateArmpits> So the issue I'm having is related to concatenating files with minimal loss. Because the audio has to fit a pattern, any following files have to be repatternized, which can lead to either a single sample loss or a single sample missing.
[00:03:31 CET] <ChocolateArmpits> Because files have fixed length, you can't guess what the missing sample should be, so I imagine padding a zero-sample is the only way out of this
[00:03:50 CET] <ChocolateArmpits> While during a loss you just have to deal with a lost sample
[00:04:00 CET] <alexpigment> what about repeating the nearest sample?
[00:04:14 CET] <ChocolateArmpits> well that sounds like an option yes
[00:04:15 CET] <alexpigment> seems safer, although i doubt you'd notice a zero sample anyway
[00:04:59 CET] <alexpigment> on the other hand, is it possible to alternate your methods from video to video
[00:05:47 CET] <ChocolateArmpits> Well upon extracting the segment back, a padded sample should disappear. I the other situation though there's nothing to do with a sample that was removed.
[00:05:54 CET] <ChocolateArmpits> In*
[00:06:45 CET] <ChocolateArmpits> Basically I found no tools that do this justly, including ffmpeg, they start mixing ending and starting samples from different files together
[00:07:12 CET] <ChocolateArmpits> Which with enough files can lead to sync issues
[00:07:38 CET] <alexpigment> yeah, i've seen that, but in my experience it has less to do with samples and more to do with just a mismatch between audio and video lengths
[00:07:49 CET] <alexpigment> i've always wanted a "pad audio" option
[00:08:20 CET] <alexpigment> well, lemme rephrase
[00:08:30 CET] <alexpigment> an audio pad option that doesn't require re-encoding
[00:09:02 CET] <ChocolateArmpits> Well in mxf the frame lengths are fixed, there's typically no variability there. The only difference is the distribution of audio samples. The audio is uncompressed btw.
[00:10:59 CET] <alexpigment> right, you've got a very different case you're working with
[00:11:15 CET] <alexpigment> generally a lot less problems with professional standards :)
[00:19:39 CET] <alexpigment> chocolatearmpits: http://www.motunation.com/forum/viewtopic.php?t=39678&p=331142
[00:19:46 CET] <alexpigment> the second post seems interesting
[00:19:53 CET] <alexpigment> not really sure if it's applicable for what you're trying to do
[00:19:58 CET] <ChocolateArmpits> I already was there lol
[00:20:04 CET] <alexpigment> oh :)
[00:20:08 CET] <alexpigment> well, there's that
[00:20:16 CET] <ChocolateArmpits> There's really little content about it, they all speak about smpte, but no doc pops up in google
[00:21:43 CET] <alexpigment> hmmm
[00:22:06 CET] <alexpigment> there are probably 5 people that could talk your ear off about this sort of thing
[00:22:21 CET] <alexpigment> and there are billions who will just scratch their heads and look at you funny
[00:22:47 CET] <alexpigment> once you get to a certain level of technical, good info and people that possess it are hard to find
[00:24:07 CET] <alexpigment> and in some cases, like with interlaced video, there is more incorrect information than correct on the internet ;)
[06:34:57 CET] <deanoman> hey all, does ffmpeg have any plans to have an update function built-in (similar to what youtube-dl does? e.g. ffmepg.exe /U)
[06:39:08 CET] <deanoman> hey all, does ffmpeg have any plans to have an update function built-in (similar to what youtube-dl does? e.g. ffmpeg.exe /U)
[06:50:02 CET] <phunyguy> Hi, I am trying to convert some flag files with embedded album art, and am running into a snag.  https://pastebin.com/BerkukMb
[06:50:07 CET] <phunyguy> flac***
[06:51:32 CET] <furq> add -vn if you just want to strip the album art
[06:51:44 CET] <phunyguy> It appears to be flipping stream 0:0 and stream 0:1 in the output because it thinks it is a video.  First, how can I revert the streams to the proper locations, and just copy the second stream?  The conventional methods of -map and -c:v copy did not appear to work.  It put the streams in the proper order but still failed to encode
[06:51:54 CET] <phunyguy> I don't want to strip the album art
[06:52:04 CET] <furq> try using .oga instead then
[06:52:09 CET] <phunyguy> I want to copy it to the new file, along with the rest of the metadata
[06:52:16 CET] <furq> also it's 2018, you should probably be using opus
[06:52:18 CET] <phunyguy> derp.  Thanks.
[06:52:27 CET] <phunyguy> think my phone would support it?
[06:52:36 CET] <furq> if it's android then sure
[06:52:40 CET] <phunyguy> ok.
[06:52:49 CET] <furq> opus is better supported than vorbis these days
[06:53:01 CET] <phunyguy> I'll look into opus.  Let me test the oga theory first.
[06:53:12 CET] <furq> .oga and .ogg use different muxers
[06:53:16 CET] <phunyguy> (been a while since I've done this, can you tell?)
[06:53:24 CET] <furq> yeah it's not super intuitive
[06:54:25 CET] <furq> ffmpeg has a specific "ogg audio" muxer
[06:54:39 CET] <furq> i assume the only difference is that it doesn't try to encode the video stream to theora
[06:55:01 CET] <furq> much like the m4a and mp4 muxers
[06:55:03 CET] <phunyguy> yep, it stripped the art
[06:55:11 CET] <phunyguy> I think it needs to be .ogg to keep it
[06:55:33 CET] <phunyguy> think opus would handle this better?
[06:55:42 CET] <furq> .opus is just ogg
[06:55:51 CET] <furq> but the muxers have different defaults so maybe that'll work better
[06:56:24 CET] <furq> also get rid of -q:v if you're using opus
[06:56:39 CET] <furq> or -q:a rather
[06:58:36 CET] <phunyguy> probably a different format, year
[06:58:37 CET] <phunyguy> yeah*
[06:58:55 CET] <phunyguy> so far it is keeping the album art... let's see when it gets to the problem one
[06:59:11 CET] <phunyguy> it's actually encoding as one stream
[06:59:49 CET] <phunyguy> or I am stupid.
[07:00:26 CET] <furq> doesn't seem to work here either
[07:00:28 CET] <phunyguy> It's still doing weird things.
[07:00:30 CET] <phunyguy>   Stream #0:1 -> #0:0 (mjpeg (native) -> theora (libtheora))
[07:00:31 CET] <phunyguy>   Stream #0:0 -> #0:1 (flac (native) -> opus (native))
[07:00:36 CET] <furq> there's a closed bug report for vorbis album art
[07:00:40 CET] <furq> or ogg album art rather
[07:00:43 CET] <furq> so i assume that should work
[07:00:55 CET] <furq> but -f opus and -f oga both just ignore the album art here
[07:01:20 CET] <phunyguy> well I expect -f oga to.  As that makes it an audio only container
[07:01:42 CET] <phunyguy> maybe opus is the same way.
[07:01:58 CET] <phunyguy> because it still needs to use an ogg container to hold the "video" stream.
[07:03:20 CET] <phunyguy> '
[07:03:29 CET] <phunyguy> ^ cat
[07:03:53 CET] <phunyguy> yeah it got to the problem album and failed.
[07:04:09 CET] <phunyguy> it's attempting to convert png to theora
[07:04:22 CET] <phunyguy> and flopping stream 0 and 1
[07:06:37 CET] <phunyguy> starting to think that stripping the art is unavoidable... unless something like mp4 will work
[07:07:04 CET] <furq> opus in mp4 isn't well supported and vorbis in mp4 isn't a thing at all
[07:07:11 CET] <phunyguy> the problem is, having all that album art as cover.jpg on my pone clutters up my picture albums.  lol.  super annoying
[07:07:22 CET] <phunyguy> I meant another codec as a whole
[07:07:26 CET] <phunyguy> probably aac
[07:07:36 CET] <furq> the builtin aac encoder is ok now
[07:07:40 CET] <furq> not as good as opus though
[07:07:55 CET] <furq> album art should definitely work with -f ipod or .m4a
[07:08:12 CET] <phunyguy> I can up the quality and sacrifice filesystem space for working album art
[07:08:24 CET] <phunyguy> will make me cry a little inside using -f ipod tho
[07:10:27 CET] <phunyguy> no go with m4a.
[07:10:52 CET] <furq> they're the same thing
[07:11:12 CET] <furq> you can use -f ipod if you really want to use .mp4 instead of .m4a and you don't want to rename afterwards
[07:12:45 CET] <furq> https://trac.ffmpeg.org/ticket/4448
[07:12:46 CET] <furq> oh fun
[07:12:52 CET] <furq> i guess that doesn't actually work then
[07:13:34 CET] <furq> you could just strip the art and then postprocess it with vorbiscomment
[07:13:36 CET] <phunyguy> nope, doesn't
[07:13:38 CET] <phunyguy> lol
[07:13:55 CET] <phunyguy> furq: yeah was hoping to avoid that.
[07:14:06 CET] <phunyguy> since the script i created is supposed to be dynamic
[07:14:44 CET] <phunyguy> also I get a warning about opus being experimental.
[07:14:48 CET] <phunyguy> so that's fun.
[07:14:50 CET] <furq> -c:a libopus
[07:14:56 CET] <furq> the builtin opus encoder sucks, same as the builtin vorbis encoder
[07:14:59 CET] <phunyguy> oh I did it wrong then
[07:15:50 CET] <phunyguy> of course I don't have it compiled in.  Why would I? This is gentoo
[07:16:04 CET] <furq> lol
[07:16:26 CET] <furq> well if it is gentoo then presumably it should at least be easy to include libfdk-aac
[07:16:34 CET] <furq> which is a better aac encoder than the builtin one
[07:17:34 CET] <phunyguy> that's enabled
[07:17:57 CET] <furq> that should be more or less the same as vorbis in terms of quality
[07:18:09 CET] <phunyguy> yep, just the container thing sucks
[07:18:21 CET] <phunyguy> I think I am stuck without album art in files.
[07:18:30 CET] <phunyguy> I mean, I can post-process, but blech
[07:18:36 CET] <furq> m4a is all right
[07:18:48 CET] <phunyguy> yes but that doesn't put album art in
[07:18:53 CET] <furq> uh
[07:18:55 CET] <furq> m4a should do
[07:19:01 CET] <phunyguy> it didn't in my test
[07:19:02 CET] <furq> i've definitely used ffmpeg for that
[07:19:36 CET] <phunyguy> I tried -f m4a and -f ipod
[07:19:42 CET] <phunyguy> both had no album art
[07:23:48 CET] <phunyguy> I think is too much variation on how the encoding software has written this album art over the years.
[07:25:19 CET] <phunyguy> and dumping the art beforehand is tough, because not everything has it
[07:28:24 CET] <phunyguy> I think my best option is to remove the album art from the flacs, dump to a folder .jpg, and just have the script copy the jpg, and encode pure audio with ffmpeg
[07:28:39 CET] <phunyguy> deal with the clutter on the phone another way
[07:29:21 CET] <phunyguy> or... OR...
[07:30:00 CET] <phunyguy> the organizing software I use has the option of dumping a cover.jpg AND embedding.  I bet I can just have the script check for cover.jpg and postprocess if so
[07:51:28 CET] <OneSploit> kepstin: I got disconnected yesterday, so you say gm107 supports only h264 right ?
[07:53:34 CET] <OneSploit> whenever I use h264_nvenc my opengl framerate drops from 60fps to 30-40fps and I see 100% CPU usage instead of 70-80% like usual
[08:08:49 CET] <theperfectpunk> I can't get to set my average bitrate in ffmpeg when encoding h264
[08:09:22 CET] <theperfectpunk> I'm using the following parameters :
[08:09:23 CET] <theperfectpunk> ffmpeg -i Trailer.mp4 -c:v h264_qsv -b:v 80000k -bufsize 120M -minrate 80M -maxrate 80M -preset veryslow -c:a libmp3lame -b:v 320k out_trailer.mp4
[08:09:39 CET] <theperfectpunk> ffmpeg -i Trailer.mp4 -c:v h264_qsv -b:v 80M -bufsize 120M -minrate 80M -maxrate 80M -preset veryslow -c:a libmp3lame -b:v 320k out_trailer.mp4
[08:12:15 CET] <theperfectpunk> pastebin : https://pastebin.com/MaunSXRC
[08:17:27 CET] <theperfectpunk> I have tried on multiple video files, the bitrate won't go higher than 3200k
[08:17:55 CET] <theperfectpunk> I'm using ffmpeg version N-89674-g57d0c24132
[08:18:44 CET] <OneSploit> I have no clue how to set decent quality for recording game with ffmpeg using h264_nvenc coded
[08:18:53 CET] <OneSploit> files look like shit and are big
[08:23:25 CET] <theperfectpunk> OneSploit: libx264 does the
[08:23:27 CET] <theperfectpunk> same
[08:24:13 CET] <theperfectpunk> OneSploit: libx264 also doesn't go higher than 3200k
[08:24:46 CET] <theperfectpunk> I have tried it on 3.4.1 too, same result
[10:35:06 CET] <durandal_1707> furq: how do you know that builtin opus encoder sucks?
[10:50:47 CET] <durandal_1707> occivink: how is your filter going?
[10:53:48 CET] <occivink> nowhere yet, I've had other priorities these days
[10:53:51 CET] <occivink> but thanks for checking on me
[10:55:34 CET] <furq> durandal_1707: why else would it be marked as experimental
[11:26:29 CET] <rav_> Hi, I am using libavformat to mux two RTP audio and video streams into a webm file. I recieve these streams as two different RTP streams on my server. Now, how do I set pts and dts values on AVPacket from these RTP timestamps ?
[12:29:39 CET] <Sam___> Does anyone know why my subtitle disappear on long text?
[12:30:15 CET] <Sam___> or how i can solve it, im ready to pay for this small solution
[13:27:31 CET] <sybariten> Hey
[13:28:10 CET] <sybariten> i'm trying to affect the bitrate, and it seems i am always getting the same filesize in the end.  Input is a somewhat weird screencast, encoded as wmv . See anything strange with this command line ?
[13:28:38 CET] <sybariten> ffmpeg -i "/data/temp/correction-201801221432-1.wmv" -ss 00:40:10 -t 00:02:45 -c:v libx264 -b:v 6M "/data/temp/correction-20180122 1432-1.mp4"
[13:28:59 CET] <sybariten> I've been doing this with 1M , 6M, 0.5M ... the resulting file is always around 4.7 megabytes
[13:29:41 CET] <sybariten> i get _heaps_ of warnings though, in the console
[13:30:00 CET] <sybariten> [libfaac @ 0x1691540] Queue input is backward in time43.32 bitrate= 219.4kbits/s dup=3770 drop=0
[13:30:01 CET] <sybariten> [mp4 @ 0x1678ce0] Non-monotonous DTS in output stream 0:1; previous: 7206922, current: 7197689; changing to 7206923. This may result in incorrect timestamps in the output file.
[13:30:34 CET] <BtbN> seems like x264 only needs a fraction of the bitrate you allowed it to use
[13:30:43 CET] <BtbN> So it will hapily leave most of it unused
[13:31:18 CET] <BtbN> See the wiki article about h264 encoding for more info on x264 encoding modes
[13:32:22 CET] <sybariten> Hmmm ok
[13:32:37 CET] <sybariten> maybe i should check what kinda bitrate i actually got, in the end. Is VLC reliable for that?
[13:32:57 CET] <BtbN> Just look at the file size?
[13:33:11 CET] <BtbN> You know how long it is, and you know the size.
[13:34:11 CET] <sybariten> almost three minutes at almost 5 megabytes
[13:41:13 CET] <DHE> sybariten: at the end of encoding, x264 prints a bunch of statistics. can you pastebin that?
[13:46:11 CET] <sybariten> DHE: sure, they are here together with the last part opf the warnings....   https://pastebin.com/ZKvj8zRq
[13:47:29 CET] <sybariten> Uh sorry, this was for a slightly different test run though...! So the numbers arent exactly as i said before. Resulting file = 1.7 Mbyte
[13:48:17 CET] <sybariten> So the combined audio+vidoe bitrate is maybe 234 kilobits?
[13:48:41 CET] <kepstin> sybariten: that should basically only happen if you have nearly blank/still video
[13:48:59 CET] <sybariten> kepstin: well you know, it's a screencast .... it's very still!
[13:49:16 CET] <sybariten> You see a web pagfe for a long time
[13:49:46 CET] <kepstin> based on those stats, it literally cannot increase the quality any higher to make the video bigger with the encoding mode you have selected.
[13:49:57 CET] <sybariten> kepstin: i see. Ok fine.
[13:50:11 CET] <kepstin> you could do lossless, that would make it bigger.
[13:50:37 CET] <sybariten> The audio gets very fragmented though, i notice now. There are regular drops, sort of like when you're listning to a bad web stream or web conference. And this is not in the source file. So i need to look into how the audio is coded
[13:51:15 CET] <kepstin> that's probably related to the timestamp issues ffmpeg is complaining about
[13:54:40 CET] <DHE> sybariten: yeah, with qp values in the single-digit range x264 is already making a super-high-quality video
[13:54:45 CET] <sybariten> kepstin: i would guess so too!
[13:56:21 CET] <OneSploit> sybariten: qp?
[13:56:27 CET] <OneSploit> you mean preset=qp ?
[13:56:53 CET] <iive> quantizer parameter
[13:57:08 CET] <OneSploit> what parameters do I need to get decent video?
[13:57:24 CET] <OneSploit> I got this https://vimeo.com/252321808
[13:57:28 CET] <OneSploit> looks aweful
[13:57:50 CET] <Sam___> Anyone who is able to help me, regarding subtitle
[13:58:06 CET] <iive> qp controls the loss and thus is most influential on quality. however
[13:58:36 CET] <iive> crf is mostly used, since it tunes qp depending on a number of other factors.
[13:59:01 CET] <OneSploit> I think I used crf=11
[13:59:05 CET] <Sam___> my subtitles disappear when there is long text, how can i solve this?
[13:59:07 CET] <iive> crf=18 should give excelent quality. For temp stuff I find 22 acceptable.
[13:59:24 CET] <OneSploit> ok so my video should be resonable
[13:59:27 CET] <OneSploit> but it looks horrible
[14:00:43 CET] <sfan5> OneSploit: are you sure that those artifacts are not present in the source video?
[14:00:46 CET] <iive> I don't see anything wrong in the video
[14:01:06 CET] <iive> e.g. the text on the left is quite crisp.
[14:01:11 CET] <OneSploit> sfan5: I dont think they are
[14:01:29 CET] <OneSploit> I use 5000 kbps preset=fast,crf=11,keyinit=1
[14:01:39 CET] <OneSploit> whatever keyinit means.. dunno but was there
[14:01:52 CET] <iive> keyframe interval...
[14:02:03 CET] <OneSploit> and Matroska MKV
[14:02:05 CET] <iive> 1 means every frame is keyframe
[14:02:21 CET] <sfan5> use either crf or bitrate, but not both
[14:02:21 CET] <OneSploit> oh what value should it be than?
[14:02:34 CET] <sfan5> and don't fiddle with the keyint setting
[14:02:35 CET] <q66> (also it's keyint, not keyinit)
[14:02:51 CET] <OneSploit> sfan5: I think simplescreenrecorder has bitrate field, so it will use both
[14:03:00 CET] <q66> it can't use both
[14:03:05 CET] <q66> they're different rate control methods
[14:03:20 CET] <Sam___> Anyone who is able to help me regarding my subtitle issue, would appreciate it
[14:03:21 CET] <OneSploit> ok so I should get rid of crf
[14:03:30 CET] <OneSploit> and use keyint=1
[14:03:39 CET] <OneSploit> but what kbps is suitable ?
[14:03:42 CET] <q66> no
[14:03:47 CET] <sfan5> you should get rid of keyint=1 and use crf
[14:03:51 CET] <q66> don't use kbps, use crf, and don't mess with keyint
[14:04:03 CET] <sfan5> Sam___: just ask your question, someone might be able to answer
[14:04:07 CET] <OneSploit> but my recorder always sets kbps
[14:04:12 CET] <sfan5> oh nvm you did already
[14:04:17 CET] <OneSploit> it has field for it
[14:04:47 CET] <iive> Sam___, I assume text subtitles. are you muxing them into a file? are you embedding them into the video?
[14:04:52 CET] <sfan5> well you could use a beter software
[14:04:55 CET] <sfan5> better*
[14:05:08 CET] <sfan5> but if you set kbps to some high-enough value, it should be fine
[14:05:10 CET] <OneSploit> sfan5: like obs which does not work and crashes...
[14:05:20 CET] <sfan5> yes yes I know that you hate obs for no good reason
[14:05:32 CET] <OneSploit> I really want to like it
[14:05:35 CET] <OneSploit> trying hard
[14:05:35 CET] <Sam___> I'm using filter complex to view subtitle on my live stream, stream is showing subtitle perfectly, until there is long speech/long text, then stream doesnt show subtitle but shows the next phrase instead.
[14:06:12 CET] <OneSploit> sfan5: oh and another thing, obs I have in debian packages has no game source
[14:06:30 CET] <OneSploit> only source is Xsh or something which particulary records whole desktop instead of opengl window alone
[14:06:35 CET] <Sam___> So basically my stream skips long subtitles
[14:06:36 CET] <sfan5> i doubt debian would ship something so broken
[14:06:45 CET] <OneSploit> wanna screenshot?
[14:06:50 CET] <OneSploit> as a proof
[14:07:07 CET] <sfan5> nah
[14:07:15 CET] <OneSploit> also I compiled obs, same issue, no "game source" or anything that resembles opengl app source
[14:07:39 CET] <OneSploit> but simplescreenrecorder has no issus with that, except forcing me to use kbps
[14:08:47 CET] <OneSploit> sfan5: so I hope you can understand my hesitation when it comes to obs.. I keep giving it a chance, but I dont think it's willing to cooperate
[14:09:10 CET] <iive> Sam___, so it is likely a bug with the subtitle filter. You might have to report a bug. Can you make a small sample file that reproduces the issue?
[14:11:43 CET] <Sam___> iive, yeah might be able to
[15:57:00 CET] <csguth> hello hello
[15:57:38 CET] <csguth> Can someone help me with building ffmpeg + x264 on win10 (msvc2015) ? I'd like to use it on pjsip.
[15:58:28 CET] <JEEB> FFmpeg can be built with MSVC, but not sure how easy x264 is to build with it. I remember trying some years ago but I don't remember if I succeeded
[15:58:50 CET] <csguth> x264 is pretty straightforward..
[15:59:08 CET] <csguth> my problem is with ffmpeg, the configure script is messing with cflags and ldflags.
[15:59:15 CET] <csguth> this is my command line:
[15:59:40 CET] <csguth> ./configure --toolchain=msvc --enable-shared --disable-static --enable-libx264 --enable-gpl --prefix=$PWD/install_prefix --extra-cflags="-I../x264-snapshot-20180118-2245/install_prefix/include" --extra-ldflags="-L../x264-snapshot-20180118-2245/install_prefix/lib"
[16:00:20 CET] <JEEB> thank you for using --prefix <3
[16:00:30 CET] <csguth> haha
[16:00:33 CET] <JEEB> anyways, in theory the cflags should come from pkg-config
[16:00:34 CET] <csguth> you're welcome
[16:00:39 CET] <JEEB> which x264 installs
[16:00:43 CET] <JEEB> (the .pc file)
[16:00:48 CET] <JEEB> prefix/lib/pkgconfig
[16:00:48 CET] <csguth> I see..
[16:01:04 CET] <csguth> let me try without the flags.
[16:01:08 CET] <JEEB> so you have to set PKG_CONFIG_PATH=/prefix/lib/pkgconfig to tell pkg-config to check there a well
[16:01:19 CET] <csguth> btw, I'm building ffmpeg 2.6.13
[16:01:23 CET] <JEEB> uhhhh
[16:01:27 CET] <JEEB> ok
[16:01:29 CET] <csguth> yeah, you're right..
[16:01:38 CET] <csguth> I just ommited PKG_CONFIG_PATH in my command
[16:01:46 CET] <JEEB> I am not sure when MSVC support was added
[16:02:00 CET] <JEEB> and there have been improvements to it along the years
[16:02:09 CET] <csguth> It seems like its using msvc..
[16:02:09 CET] <JEEB> I think the support was added circa 2013
[16:02:22 CET] <csguth> but it's trying to use /L../x264...
[16:02:31 CET] <csguth> Instead of /LIBDIR or something like this
[16:02:36 CET] <JEEB> ok, that then comes from the .pc file
[16:02:39 CET] <JEEB> most likely?
[16:02:46 CET] <csguth> I hope so...
[16:02:52 CET] <csguth> I'm running configure
[16:03:16 CET] <csguth> With the right PKG_CONFIG_PATH :)
[16:03:33 CET] <JEEB> so either you tell configure to give additional params to pkg-config (it might have had an option to convert options from GCC style to MSVC, otherwise just edit the .pc file)
[16:03:56 CET] <JEEB> there's --pkg-config-flags=FLAGS
[16:04:04 CET] <JEEB> for additional flags to be given to pkg-config
[16:04:08 CET] <csguth> uhhhh
[16:04:30 CET] <JEEB> and if you can't find an option to do the conversion, then just modify the .pc file
[16:04:37 CET] <csguth> ok
[16:04:49 CET] <csguth> I didn't try this yet..
[16:05:21 CET] <csguth> let me wait for the configure command (without pkg flags) to finish.
[16:05:22 CET] <JEEB> ok, there seems to be --msvc-syntax in pkg-config
[16:05:33 CET] <JEEB> looking at https://linux.die.net/man/1/pkg-config
[16:05:39 CET] <csguth> Yep, there is.. I used it in some other project.
[16:08:37 CET] <csguth> trying with --pkg-config-flags="--msvc-syntax"
[16:13:11 CET] <csguth> hmm
[16:13:31 CET] <csguth> still not working.. but now I believe the problem is the win32 syntax for file paths..
[16:13:46 CET] <JEEB> yea, msys can be weird :P
[16:13:48 CET] <csguth> I'm gonna change the .pc file to use /c/Program Files/ ...
[16:13:55 CET] <csguth> instead of C:\...
[16:14:14 CET] <csguth> ooppps
[16:14:30 CET] <csguth> the .pc file is using /c/...
[16:15:15 CET] <csguth> config.log is pointing "ignoring unknown option '/libpath:C:/path/to/lib'
[16:16:39 CET] <csguth> on cl.exe
[16:17:05 CET] <csguth> how strange..
[16:17:10 CET] <csguth> cl is using /libpath
[16:17:15 CET] <csguth> and link is using -I
[16:17:18 CET] <csguth> ¬¬
[16:18:33 CET] <csguth> I guess it's using both flags on both programs.. nevermind.
[16:53:20 CET] <TAFB> if I want to convert a 4k "REMUX.HEVC.DTS-HD.MA.5.1" down to 1080p but I want it to be super sharp (whenever I've tried to use ffmpeg to reduce ther resolution it always blurs it a bit), what's the secret?
[16:54:55 CET] <TAFB> I'm using "ffmpeg -i 4k.mp4 -vf scale=1920:-1 1080p.mp4"
[16:59:01 CET] <TAFB> -sws_flags lanczos+print_info??????
[17:00:21 CET] <c_14> have you tried using a different scalar?
[17:00:22 CET] <c_14> say bicubic?
[17:01:54 CET] <TAFB> bicubic is the default, no?
[17:02:13 CET] <c_14> yeah
[17:02:36 CET] <TAFB> there is for sure some blurring filter going on with bicubic
[17:04:56 CET] <TAFB> i'm going to try lanczos on a short clip and see if it's sharper
[17:18:46 CET] <DHE> there's also the colour depth. yuv420 is standard but yuv444 will give a better image.
[17:19:02 CET] <DHE> but a lot of video players, especially hardware like smart TVs, will only accept yuv420
[17:22:26 CET] <TAFB> yuv444 works with h264?
[17:22:52 CET] <TAFB> i think that might help because I see lots of colour banding after the converting (even with crf 0)
[17:22:58 CET] <DHE> yes, but it requires a player with Main444 or High444 etc profile support. The defaults of Main and High only specify yuv420
[17:23:31 CET] <DHE> okay, apparently there is no such thing as Main444. but you get the idea
[17:27:39 CET] <TAFB> ok, running a test convert now with -pix_fmt yuv444p
[17:33:39 CET] <TAFB> -sws_flags neighbor seems to look sharpest, yuv444 got rid of the colour banding :) looking real nice now, thanks!
[18:14:08 CET] <myName_> I have week cpu, I want to save mjpeg stream to images as jpeg files,   ffmpeg -i http://..... image%d.jpeg   but then I see that ffmpeg save t me only 2.5~3 images per secondes.  (that ok i know i have week cpu) but when i add filter to save only 2 images per seconds i see that ffmpeg saved only 0.6~0.8 images per secondes, why??  ffmpeg -i http://..... -vf fps=2 images%d.jpeg
[18:15:21 CET] <kepstin> myName_: maybe the problem is that decoding the video is slow.
[18:15:36 CET] <myName_> how can i fast decoding??
[18:19:49 CET] <Johnx_> Quick question regarding ffmpeg, i have a python script that uses ffmpeg to check for udp streams for errors. I have noticed that when ffmpeg is paired with sleep or timeout, it doenst output any errors other than just header connection info: https://pastebin.com/VnPMQe70
[18:20:52 CET] <Johnx_> the moment sleep or/and timeout is removed, i get the usual list of errors, like co-located , etc...
[18:21:36 CET] <Johnx_> any suggestions on what can be done to get ffmpeg to output all decoding errors when paired with sleep and timeout
[18:21:46 CET] <Johnx_> i am on cent 7
[18:22:39 CET] <myName_> kepstin: how can i fast decoding ? that mjpeg stream not 264 . i cna't use preset ultrafast
[18:23:51 CET] <kepstin> myName_: actually, if the original stream is jpeg, there's no reason to encode or decode at all. Try adding the "-c copy" option.
[18:24:29 CET] <c_14> can't adjust the fps to drop images then though
[18:25:23 CET] <myName_> kepstin: that mjpeg stream 1, when i use decode i see i get only 20 fps not 25 so i see 0.8x (so that not good video)  2, now i tried to get 2-3 images per seconds
[18:32:49 CET] <c_14> have you ever tried with -c copy?
[18:33:20 CET] <myName_> c_14, yes when i use -c copy i get only 0.8x speed
[18:34:04 CET] <kepstin> myName_: what are you writing the files to? Is it an SD card or something? maybe that's too slow.
[18:34:52 CET] <myName_> kepstin yes it is ,
[18:38:37 CET] <myName_> kepstin: but on top conad i see that my prolem is cpu not io
[18:39:20 CET] <kepstin> What percentage is iowait?
[19:01:45 CET] <myName_> kepstin: what do you mean? how can i check it ?
[19:10:37 CET] <saml> what's difference between -psnr and -filter_complex psnr?   looks like -psnr is taking one input and during encoding process, it calulates psnr
[19:10:49 CET] <saml> not sure how -psnr would work if I specify different -r and -s
[19:11:17 CET] <saml> -filter_complex psnr  requires both reference and main video to have same dimension and framerate
[19:28:09 CET] <saml> so, -psnr -tune psnr is good.  but -filter_complex psnr no good bro
[19:28:15 CET] <saml> oh man psnr just die
[19:40:06 CET] <kepstin> saml: the psnr filter is a filter that can be used to calculate psnr between any two arbitrary video streams, and it runs in the filter chain before the encoder. The '-psnr' option, tells the encoder to calculate the psnr between its input and its output
[19:41:54 CET] <kepstin> saml: the "-tune psnr" option of course does something completely different - it tells the x264 encoder to encode the video optimized in a way to make psnr as high as possible. This makes the visual quality lower.
[19:51:07 CET] <saml> so, I do this  ffmpeg -i 4k.webm -psnr -tune psnr -pix_fmt rgb24 -r 10 -s 480x270 -vcodec libx264rgb -acodec aac a.mp4
[19:51:15 CET] <saml> I get 43 Average PSNR
[19:51:29 CET] <saml> now I do this ffmpeg -i a.mp4 -i 4k.webm -filter_complex "scale2ref [vid][ref]; [vid][ref] psnr" -f null -
[19:51:37 CET] <saml> a.mp4 is the output of previous encoding
[19:51:42 CET] <saml> I get 27 PSNR
[19:52:02 CET] <saml> i also tried more complex filter graph  scale2ref [vid][ref]; [vid] format=pix_fmts=yuv420p [vid_f]; [ref] format=pix_fmts=yuv420p [ref_f]; [vid_f] framerate [vid_fr]; [ref_f] framerate [ref_fr]; [vid_fr][ref_fr] psnr
[19:52:18 CET] <saml> that barely gives me 1 more PSNR (27.8)
[19:52:57 CET] <saml> i think, once video is scaled during encoding,  i cannot use psnr filter to calculate "original" psnr values that were calculated during encoding
[19:53:14 CET] <saml> that also means what i'm doing with psnr filter is useless almost
[19:53:22 CET] <saml> hehehehehehhehehehehehehehehehehehehehehehe
[19:53:42 CET] <kepstin> well, I don't know what you're trying to do with the psnr filter, but yes - attempting to make it show the same number as a different thing is quite useless
[19:55:56 CET] <sfan5> are you taking the psnr of the upscaled video there?
[20:05:46 CET] <saml> sfan5, yes
[20:06:05 CET] <sfan5> i wouldn't expect that to work
[20:06:20 CET] <sfan5> you should scale the reference down and then compare ref & output
[20:06:33 CET] <saml> ah i thought i was scaling reference down, actually
[20:06:56 CET] <saml> yeah i'm scaling ref down
[20:07:05 CET] <sfan5> my mistake, then
[20:07:40 CET] <saml> or i'm wrong
[20:08:14 CET] <saml> https://www.ffmpeg.org/ffmpeg-all.html#scale2ref   i'm assuming first argument is video. second input is ref.
[20:08:22 CET] <saml> oh yeah i'm wrong
[20:08:42 CET] <saml> i should pass ref first so that ref will be scaled down to vid
[20:08:44 CET] <saml> thanks
[20:10:19 CET] <myName_> how can i faster the encoder when i save mjpeg stream to avi file
[20:12:24 CET] <saml> by scaling ref down, i get PSNR up to 29.4
[20:12:26 CET] <saml> win
[20:12:44 CET] Action: saml looks into vmaf
[20:13:26 CET] <sfan5> why would you ever optimize your video for high PSNR though?
[20:39:39 CET] <saml> sfan5, no idea
[20:40:03 CET] <saml> i think some books are written for psnr as main example
[20:47:56 CET] <myName_>  how can i faster the encoder when i save mjpeg stream to avi file
[20:51:39 CET] <BtbN> More cores
[20:51:48 CET] <BtbN> Or faster ones
[20:53:56 CET] <saml> are you implementing gyfcat or something?
[20:55:40 CET] <sfan5> gfycat uses h.264 w/o audio inside .mp4 as a gif replacement
[20:55:43 CET] <sfan5> so no mjpeg involved
[20:56:13 CET] <saml> ah i see.
[20:56:25 CET] <saml> i didn't know what mjpeg was
[20:56:27 CET] <myName_> how can i faster the encoder when i save mjpeg stream to avi file
[20:56:46 CET] <saml> myName_, do you have command line that you're using?
[20:57:02 CET] <saml> or are you using libraries?
[20:58:37 CET] <myName_> saml: ffmpeg -i http://......(mjpeg stream) -c:v copy 1.avi
[20:59:35 CET] <saml> if you're using copy as codec... i wonder if bottleneck is http request
[20:59:38 CET] <kepstin> myName_: if that can't do realtime, then either your storage device is too slow, network is too slow, or cpu is too slow (in that order) and there's not really much we can do about it.
[21:00:09 CET] <saml> have you tried  curl http://.... -o a.mjpeg;    ffmpeg -i a.mjpeg -c:v copy 1.avi
[21:04:19 CET] <alexpigment> myName_ are you the same person as "sdds" from yesterday?
[21:33:09 CET] <SortaCore> what's the profile/level etc support of openh264?
[21:33:18 CET] <SortaCore> https://github.com/cisco/openh264/blob/master/README.md says just constrained baseline up to level 5.2
[21:35:38 CET] <SortaCore> https://github.com/cisco/openh264/blob/master/codec/encoder/core/src/encoder_ext.cpp#L130 says main/high as well
[21:40:22 CET] <JEEB> SortaCore: since constrained baseline is a subset of main/high I wouldn't be surprised if you can set the stream to be advertised as main/high
[21:40:35 CET] <JEEB> but I don't think openh264 actually can encode more than constrained baseline
[21:41:40 CET] <kepstin> i'm pretty sure the decoder can't decode anything above baseline either
[21:41:47 CET] <DHE> the level is more a measure of CPU power than anything else, so 5.2 is possible if you have a beast of a CPU...
[21:41:53 CET] <DHE> then again baseline is probably really easy to do
[21:42:28 CET] <SortaCore> so decoding is probably ok with everything, but encoding is constrained baseline only?
[21:42:38 CET] <JEEB> no, decoding is most likely limited, too :P
[21:42:50 CET] <JEEB> DHE: to be exact level is "how much memory the decoder requires to decode this"
[21:42:51 CET] <JEEB> :P
[21:42:55 CET] <SortaCore> _nuu_
[21:43:04 CET] <JEEB> since it controls bit rate / amount of reference frames
[21:43:27 CET] <JEEB> and the latter decides how much memory the decoder has to hold to keep those
[21:43:32 CET] <kepstin> last I checked, their decoded didn't implement features required to decode any profiles higher than constrained baseline
[21:43:39 CET] <kepstin> so it'll fail to decode main or high
[21:43:42 CET] <JEEB> yea
[21:44:02 CET] <JEEB> otherwise firefox etc could use those cisco binaries for all the H.264 :P
[21:44:03 CET] <DHE> JEEB: it also decides number of macroblocks, which is effectively image resolution
[21:44:17 CET] <DHE> *per second, so framerate as well
[21:44:26 CET] <JEEB> yes
[21:44:31 CET] <JEEB> that's where the ref count comes IIRC
[21:44:49 CET] <JEEB> size in macroblocks VS amount of refs basically
[21:44:49 CET] <DHE> ref frames for RAM, blocks*framerate for CPU power
[21:45:07 CET] <DHE> so, both
[21:45:18 CET] <SortaCore> rawr
[21:45:24 CET] <JEEB> basically the less macroblocks the more refs because a single image takes less memory
[21:45:43 CET] <JEEB> but generally decoders that actuall care about levels aren't using a CPU anyways :P
[21:51:59 CET] <SortaCore> I'm trying to set up this interface for a developer to select encoding settings - trying to work out what codecs support which parameter types
[21:52:08 CET] <SortaCore> like preset
[21:53:15 CET] <ChocolateArmpits> SortaCore, run ffmpeg -help encoder=[encoder name]
[21:54:00 CET] <ChocolateArmpits> to get a list of encoders: ffmpeg -encoders
[22:01:11 CET] <SortaCore> yea, that helps a bit Choc
[22:01:30 CET] <SortaCore> although, with the number of options available, I'd need an AI to work out the best :p
[22:02:25 CET] <SortaCore> what's trellis?
[22:06:08 CET] <GyrosGeier> SortaCore, https://en.wikipedia.org/wiki/Trellis_modulation
[22:06:33 CET] <GyrosGeier> this maps a bitstream to another bitstream of the same length
[22:07:25 CET] <GyrosGeier> but with better error correction properties
[22:07:28 CET] <SortaCore> okay, is color primary and color range passed to libx264 encoder if called via C++?
[22:07:48 CET] <SortaCore> so trellis is good
[22:08:06 CET] <GyrosGeier> it depends on your use case
[22:08:14 CET] <GyrosGeier> if you have a noisy channel, yes
[22:08:22 CET] <GyrosGeier> otherwise, it's useless
[22:08:33 CET] <JEEB> wrong trellis
[22:08:40 CET] <GyrosGeier> oh?
[22:09:24 CET] <GyrosGeier> I thought it was used for transport streams to improve error detection
[22:09:32 CET] <JEEB> this was about libx264
[22:09:38 CET] <GyrosGeier> sorry for the confusion then
[22:09:42 CET] <JEEB> where trellis quantization is utilized for various things :P
[22:09:56 CET] <JEEB> there's even a thing called psy-trellis :P
[22:10:07 CET] <SortaCore> well, I'm using trellis in multiple encoders
[22:10:21 CET] <JEEB> anyways, generally for x264 you just give the user the presets, tunes and profile+level if limitation is needed. if you really need more custom stuff, let them pass libx264 API key=value pairs into x264-params
[22:10:24 CET] <SortaCore> is it all the same concept in all of them
[22:10:27 CET] <JEEB> that's my general opinion
[22:10:59 CET] <SortaCore> that's basically what I'm doing
[22:11:21 CET] <JEEB> for streaming etc you need some additional parameters like VBV/HRD maxrate/bufsize and HRD signaling mode, but those start going into "I know my stuff" territory
[22:11:22 CET] <SortaCore> but because QSV doesn't have tune support, I can at least tell the user when they pick QSV and then pick tune, it will be ignored
[22:13:11 CET] Action: GyrosGeier needs a sane preset for reencoding an NTSC DVD
[22:13:33 CET] <SortaCore> because codecs have the habit of aborting in avcodec_open2 when the values are unsupported - instead of just picking something close
[22:13:34 CET] <GyrosGeier> 480i
[22:13:47 CET] <SortaCore> and they don't provide any useful error info in QSV's case
[22:14:27 CET] <SortaCore> I'm getting a stream and it has JPEG color range, and not sure if libx264 is getting passed that, as the output mp4 files come up as full color range
[22:14:35 CET] <GyrosGeier> if I attempt to deinterlace, the resulting video is not sanely compressible anymore
[22:15:03 CET] <JEEB> SortaCore: you have to work pretty hard to get libx264 to mark YCbCr as full range
[22:15:12 CET] <JEEB> in libx264 itself as well as libavcodec
[22:15:29 CET] <JEEB> so if you're taking stuff in that's marked as limited range, that should stay as-is :P
[22:16:45 CET] <ChocolateArmpits> GyrosGeier, imo most deinterlacers are catastrophic except for qtgmc.
[22:17:37 CET] <GyrosGeier> I've tried "-flags +ilme" to keep the content interlaced
[22:18:01 CET] <ChocolateArmpits> GyrosGeier, you need -x264-params tff/bff=1:interlaced=1 also the "full set" is -flags +ildct+ilme
[22:18:42 CET] <GyrosGeier> some of the material was shot with an NTSC camera from the back of a fighter plane, the two fields look nothing alike :P
[22:18:43 CET] <ChocolateArmpits> for tff/bff pick your field order
[22:18:48 CET] Action: GyrosGeier reboots and tries
[22:19:05 CET] <ChocolateArmpits> as in it's either "tff" or "bff"
[22:19:53 CET] <alexpigment> ChocolateArmpits: the x264-params part is unnecessary is the source is interlaced, in my experience
[22:20:19 CET] <alexpigment> the "-flags +ildct+ilme" will preserve the interlacing and make x264 use MBAFF
[22:20:48 CET] <ChocolateArmpits> well I punch in everything to cover any imaginary situation
[22:20:49 CET] <alexpigment> honestly, i think one of those flags is even unnecessary, but i've never gotten around to remembering which one it is, because it doesn't hurt anything to specify both
[22:21:00 CET] <SortaCore> JEEB: No, it's dropping it, maybe due to YUVJ codec? https://pastebin.com/raw/q5h1dYiE
[22:21:33 CET] <JEEB> "Stream #0:0: Video: h264 (High), yuvj420p(pc, bt709, progressive)"
[22:21:35 CET] <alexpigment> ChocolateArmpits: understandable
[22:21:35 CET] <JEEB> > pc
[22:21:42 CET] <JEEB> that is *full* range
[22:21:57 CET] <JEEB> so yes, ffmpeg.c is actually passing that information through there :P
[22:22:00 CET] <SortaCore> YUVJ420P is YUV420P with jpeg color range though?
[22:22:09 CET] <JEEB> yes, but the metadata is more important tbh
[22:22:10 CET] <kepstin> jpeg range is the same thing as full range
[22:22:13 CET] <kepstin> aka pc range
[22:22:20 CET] <JEEB> or well, that's where you should see it
[22:22:27 CET] <JEEB> at some point the "J" pix_fmts will go away
[22:22:38 CET] <JEEB> they're an old leftover from ye olden days :P
[22:22:47 CET] <SortaCore> yea, I'm just seeing the output file in MediaInfo, and it says "full range" where I'm expecting "jpeg range"
[22:22:54 CET] <SortaCore> if they're synonyms then no prob
[22:22:57 CET] <JEEB> yes
[22:23:06 CET] <JEEB> full range is the generic way of saying it
[22:23:25 CET] <JEEB> tv/limited range is the generic way of saying 16-235/240
[22:24:06 CET] <alexpigment> GyrosGeier: fwiw, I usually keep things interlaced if I'm being lazy, but you really need to first decide if your content is telecined, fake interlaced (e.g. 30p native) or true interlaced. I have a different process for each scenario, personally
[22:24:09 CET] <SortaCore> what is the pc part?
[22:24:36 CET] <JEEB> ffmpeg.c/ffprobe.c note it as "tv" (16-235/240) or "pc" (0-255)
[22:24:50 CET] <JEEB> 99% of all video in the world is TV/limited range :P
[22:25:02 CET] <JEEB> and pretty much just screen capture formats encode in full range
[22:25:06 CET] <kepstin> SortaCore: pc as in "personal computer". PC screen output is full range.
[22:25:37 CET] <GyrosGeier> hm
[22:25:43 CET] <SortaCore> alright, I've also seen "mpeg range" knocking about
[22:25:47 CET] <kepstin> (notably, this means that since 99% of video is limited range, all pc video players have to convert to full range for display)
[22:25:59 CET] <JEEB> SortaCore: that's what some things call limited range since video is 99% limited range
[22:26:03 CET] <JEEB> :P
[22:26:04 CET] <kepstin> mpeg range is another synonym for tv range or limited range
[22:26:04 CET] <GyrosGeier> the DVD has a big NTSC logo on it, so I suspect it's proper 30000/1001
[22:26:20 CET] <kepstin> jpeg = pc = full in contrast to mpeg = tv = limited
[22:26:20 CET] <alexpigment> GyrosGeier: yes, but there are best practices for the source format
[22:26:35 CET] <SortaCore> three names for the same thing (thumbs up) :p
[22:26:36 CET] <alexpigment> for example, for film sourced material, it's best to detelecine
[22:27:02 CET] <JEEB> interlaced fields can be thought of as a container :P
[22:27:14 CET] <SortaCore> could someone put a code comment in where the color ranges are defined?
[22:27:15 CET] <JEEB> content can be whatever, as many people have seen during the years
[22:27:38 CET] <SortaCore> with the a.k.a's, should leave less questions in future
[22:27:50 CET] <GyrosGeier> hmmm
[22:28:01 CET] <GyrosGeier> the source material is Super8 and 16mm
[22:28:28 CET] <kepstin> GyrosGeier: in that case it'll be telecined. do you know the original film framerate?
[22:28:43 CET] <kepstin> it's probably either 12 or 24, in which case it would be the normal 2:3 telecine pattern.
[22:28:44 CET] <alexpigment> GyrosGeier: oh fun. the detelecining process for that is kinda wonky
[22:28:53 CET] <alexpigment> super8 is 16 or 18 i thought...
[22:28:58 CET] <kepstin> oh, great
[22:28:59 CET] <JEEB> SortaCore: https://ffmpeg.org/doxygen/trunk/pixfmt_8h.html#a3da0bf691418bc22c4bcbe6583ad589a
[22:29:02 CET] <GyrosGeier> well, probably "mixed"
[22:29:20 CET] <alexpigment> in this scenario, i'd just stay with interlaced ;)
[22:29:25 CET] <GyrosGeier> so I'd have to switch in the middle of the stream
[22:29:27 CET] <kepstin> GyrosGeier: well, what you can do depends entirely on how the framerate conversion was done :/
[22:29:28 CET] <JEEB> although it still utilizes the "MPEG"/"JPEG" nomenclature :P
[22:29:30 CET] <SortaCore> yea, they're defined as RGB ranges, that's fine, but the alternative names of the ranges would help too
[22:29:43 CET] <JEEB> ...
[22:29:46 CET] <SortaCore> so future people don't get puzzled like I did
[22:29:48 CET] <JEEB> where do you see RGB there?
[22:29:55 CET] <JEEB> "the normal 219*2^(n-8) "MPEG" YUV ranges"
[22:29:59 CET] <SortaCore> I meant the numbers
[22:30:10 CET] <JEEB> they're not RGB ranges
[22:30:34 CET] <SortaCore> force of habit
[22:31:25 CET] <SortaCore> but yea, if by their names they also had their alternative names, it would clarify things
[22:31:57 CET] <GyrosGeier> do I need "-g 300"?
[22:32:22 CET] <kepstin> GyrosGeier: you don't "need" it, why do you have it in the first place?
[22:33:03 CET] <kepstin> GyrosGeier: increasing the gop size (~keyframe interval) can improve encoding efficiency but it'll make seeking slower.
[22:33:29 CET] <alexpigment> i personally like to use -g [same as framerate], but i know others would probably think that's excessive
[22:33:46 CET] <alexpigment> i just care more about seeking than I do small file sizes
[22:34:02 CET] <kepstin> same as framerate gives a keyframe every second, which will give responsive seeking but larger files, particularly in video that's generally low motion
[22:34:03 CET] <alexpigment> and i prefer to feel like i'm using an appliance than a computer when I use my HTPC :)
[22:35:01 CET] <GyrosGeier> with just -flags +ildct+ilme and 1024kbps, the quality is bad
[22:35:16 CET] <alexpigment> do you need it to be 1024kbps?
[22:35:23 CET] <alexpigment> that seems low to me
[22:35:25 CET] <GyrosGeier> ah
[22:35:52 CET] <GyrosGeier> the source material is MPEG2 with 8500kbps
[22:36:04 CET] <kepstin> source bitrate is irrelevant, of course.
[22:36:13 CET] <kepstin> GyrosGeier: unless you are targetting a specific filesize, you should use the "-crf" option instead of setting a bitrate. The default is -crf 24 i think?
[22:36:21 CET] <kepstin> lower numbers are higher quality - adjust to taste.
[22:36:42 CET] <kepstin> generally around 18 and lower is considered "very high" quality.
[22:37:47 CET] <GyrosGeier> with -crf 24, it uses 693kbps
[22:38:30 CET] <GyrosGeier> hm, that option does nothing
[22:38:52 CET] <kepstin> GyrosGeier: hmm, wait a minute, what codec are you encoding with?
[22:39:54 CET] <GyrosGeier> ah
[22:39:55 CET] <alexpigment> does it start with a v and end with p8? ;)
[22:40:00 CET] <GyrosGeier> that is part of the problem
[22:40:15 CET] <GyrosGeier>     Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 720x480 [SAR 8:9 DAR 4:3], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
[22:40:18 CET] <kepstin> GyrosGeier: you'll probably want to add a "-c:v libx264" in there :)
[22:40:40 CET] <kepstin> hmm, the sar on that video is wrong
[22:40:59 CET] <kepstin> (it's close enough that most people won't notice tho)
[22:41:30 CET] <alexpigment> kepstin: how so?
[22:41:48 CET] <kepstin> ntsc "4:3" video in a 720x480 frame has a sar of 10/11
[22:41:53 CET] <alexpigment> hmmmm
[22:41:59 CET] <alexpigment> are you sure?
[22:42:08 CET] <alexpigment> is it possible you're thinking of 704x480?
[22:42:23 CET] <kepstin> 704x480 has the same sar
[22:42:46 CET] <kepstin> you turn 720x480 into 704x480 by cropping off 8px on each side
[22:42:49 CET] <GyrosGeier> now encoding is a lot slower, I take that as a good sign
[22:43:19 CET] <alexpigment> kepstin: that actually depends, in my experience
[22:43:30 CET] <kepstin> which means that the 720x480 is actually slightly *wider* than 4:3, and it contains stuff on the edges that's normally out of frame when shown on a tv
[22:43:33 CET] <alexpigment> you can use the full 720x480 if you want, but most broadcast doesn't
[22:43:42 CET] <SortaCore> how do you invoke NVENC for encoding?
[22:43:57 CET] <alexpigment> sortacore: -c:v h264_nvence
[22:44:00 CET] <alexpigment> gah
[22:44:04 CET] <alexpigment> h264_nvenc
[22:44:09 CET] <SortaCore> yea, that's using cpu though
[22:44:18 CET] <alexpigment> it uses some for decoding
[22:44:19 CET] <SortaCore> 0% GPU usage
[22:44:26 CET] <alexpigment> well, that's another story :)
[22:44:27 CET] <GyrosGeier> yes, the result is way better now
[22:44:52 CET] <kepstin> alexpigment: whether or not there's stuff in the extra pixels in 720x480 depends, there's usually something in there. But either way, displaying 720x480 as 4:3 is wrong.
[22:45:04 CET] <SortaCore> I tried putting the input into dxva2, and it switched the pixel format to NV12 in output, but still 0% GPU usage
[22:45:05 CET] <GyrosGeier> alexpigment, IIRC NTSC only guarantees 400 pixels vertically to be visible
[22:45:20 CET] <alexpigment> ?
[22:45:28 CET] <alexpigment> i work a lot with 480i
[22:45:33 CET] <kepstin> that's not relevant, we're talking about horizontal here ;)
[22:46:09 CET] <kepstin> and ntsc doesn't have anything named "pixels" in any specifications anywhere ;)
[22:46:25 CET] <GyrosGeier> at least the 640x400 usable pixels on my Amiga are close to the edges of my CRT :/
[22:46:42 CET] <alexpigment> anyway, i've got a bunch of material that's 720x480. it's all 8:9
[22:47:19 CET] <kepstin> alexpigment: it *should* be 10/11, whatever's giving you the 8/9 number is doing something wrong (it's assuming that the 720x480 corresponds to 4:3, which is incorrect)
[22:47:19 CET] <GyrosGeier> can I use multiple threads or OpenCL to speed up encoding?
[22:47:33 CET] <alexpigment> kepstin: do you have any 480i? you mind just double checking?
[22:47:34 CET] <SortaCore> any ideas about nvenc? *stares hard at it*
[22:47:50 CET] <alexpigment> sortacore: do you have a monitor plugged into the nvidia gpu?
[22:47:56 CET] <SortaCore> yep
[22:48:01 CET] <alexpigment> recent drivers?
[22:48:06 CET] <SortaCore> updated last week
[22:48:15 CET] <alexpigment> do you have mediainfo, by chance?
[22:48:19 CET] <SortaCore> I have intel and nvidia cards, one screen plugged into both
[22:48:26 CET] <SortaCore> yea, I just updated it a couple minutes ago
[22:48:30 CET] <alexpigment> if so, you can verify whether x264 info is being written into the file
[22:48:31 CET] <SortaCore> using it to look at color range
[22:48:42 CET] <SortaCore> nani
[22:48:48 CET] <kepstin> alexpigment: one thing to note is that a lot of old mpeg file formats are usually mistagged as to aspect ratio
[22:49:00 CET] <kepstin> alexpigment: and ffmpeg doesn't read the aspect ratio of dvd vobs correctly
[22:49:09 CET] <alexpigment> kepstin: maybe so. i record in 480i daily
[22:49:14 CET] <alexpigment> it's always 8:9
[22:49:21 CET] <alexpigment> not sure why it's always been wrong
[22:49:26 CET] <alexpigment> looks right
[22:49:33 CET] <alexpigment> circles are circles, etc
[22:49:33 CET] <kepstin> hmm, well, then all your video is just very slightly too narrow :/
[22:49:58 CET] <kepstin> it's only a <1% difference, so it's hard to tell
[22:50:00 CET] <kepstin> iirc
[22:50:17 CET] <kepstin> er wait, no, it's about 3%
[22:50:29 CET] <SortaCore> alexpigment: x264?
[22:50:46 CET] <GyrosGeier> bframes=3 b_pyramid=2 -- that's a fairly low profile
[22:51:00 CET] <SortaCore> I'm getting a h264 rtsp stream, I'm transcoding it with a hwaccel'd encoder, hopefully
[22:51:01 CET] <alexpigment> SortaCore: i was just asking in case it was punting and using x264 instead
[22:51:15 CET] <SortaCore> Stream #0:0: Video: h264 (h264_nvenc) (Main) (avc1 / 0x31637661), nv12, 704x480, q=-1--1, 2000 kb/s, 6.25 fps, 12800 tbn, 6.25 tbc
[22:51:16 CET] <GyrosGeier> should I tune that, given that all modern players will have space for quite a few reference frames?
[22:51:37 CET] <SortaCore> I either get NV12 or YUV420P, but in either case no GPU usage
[22:51:38 CET] <GyrosGeier> hmm wait
[22:51:56 CET] <GyrosGeier> lots of "Past duration 0.999992 too large"
[22:52:02 CET] <kepstin> alexpigment: if you want to know *why* it's 10/11 and why a lot of stuff gets it wrong, go and read https://lurkertech.com/lg/video-systems/#pixelaspect :)
[22:52:17 CET] <GyrosGeier> is that bad?
[22:52:23 CET] <kepstin> GyrosGeier: can you please share your full command line and a bigger chunk of output?
[22:52:41 CET] <kepstin> GyrosGeier: that message can indicate that you're getting dropped frames, which might be noticable.
[22:52:43 CET] <alexpigment> kepstin: again, i think it's because you're assuming that my content is 704x480; it's not
[22:52:55 CET] <GyrosGeier> $ ffmpeg -i stream.dump -c:v libx264 -crf 24 -flags +ildct+ilme ~/Sir_No_Sir.mkv
[22:52:55 CET] <kepstin> alexpigment: i'm assuming your content is 4:3 ntsc
[22:53:15 CET] <kepstin> alexpigment: which, if it's sampled at the standard rate for 720x480 or 704x480, has a sar of 10/11
[22:53:26 CET] <kepstin> doesn't matter which res it is, the sar is the same
[22:53:41 CET] <kepstin> 704 just has less of the width of the signal than 720 does
[22:53:51 CET] <GyrosGeier> the errors start at 5 minutes into the stream
[22:54:24 CET] <alexpigment> GyrosGeier: is it possible that the frame rate changes at some point in the stream?
[22:54:28 CET] <kepstin> GyrosGeier: that error indicates that ffmpeg guessed that the framerate was constant, but partway through the stream it started getting frames at a faster rate.
[22:55:06 CET] <GyrosGeier> alexpigment, is that legal for DVDs?
[22:55:21 CET] <SortaCore> *FBI kicks down door*
[22:55:24 CET] <alexpigment> sadly, it's legal for a lot of video ;)
[22:55:31 CET] <GyrosGeier> looking at the output file, A-V sync seems good at 10 minutes in
[22:55:31 CET] <alexpigment> SortaCore: lol
[22:55:34 CET] <SortaCore> *FBI droops head and walks out slowly*
[22:55:41 CET] <kepstin> GyrosGeier: ffmpeg's dvd handling is weird, particularly for content that was encoded in mixed pseudo-progressive and interlaced/telecined
[22:56:04 CET] <kepstin> GyrosGeier: don't worry, it'll maintain sync fine. but the video mgiht be juddery.
[22:56:30 CET] <GyrosGeier> kepstin, I'm feeding it a PS stream, read using mplayer -dumpstream
[22:56:49 CET] <kepstin> GyrosGeier: just a moment, i'm looking up the filter to fix it
[22:57:46 CET] <kepstin> GyrosGeier: add "-vf repeatfields" - that filter will turn the video into a constant 30/1.001fps interlaced stream instead of the mixed 24 & 30 that ffmpeg sometimes does.
[22:59:29 CET] <alexpigment> kepstin: fyi, i'm looking through tons of sources over here. if you can find a non-widescreen NTSC video that *ffmpeg* reports at something other than 8:9, i'll be very surprised
[22:59:33 CET] <GyrosGeier> so I can't have an output file that switches framerate together with the input?
[22:59:49 CET] <JEEB> why not?
[23:00:03 CET] <JEEB> FFmpeg's framework is 100% timestamp based and mp4/matroska etc are timestamp based
[23:00:08 CET] <kepstin> alexpigment: stuff in mpeg containers (mpeg-ps particularly) will usually be wrong. Most DV content should be correct.
[23:00:15 CET] <alexpigment> kepstin: i understand what you're saying intellectually. i'm not saying *you're* wrong, but between you and ffmpeg, one of you is
[23:00:33 CET] <alexpigment> well in that case, i never use DV
[23:00:41 CET] <alexpigment> always MPEG-2 and H.264 sources
[23:01:21 CET] <kepstin> alexpigment: what container?
[23:01:22 CET] <alexpigment> and always in ps or ts, for that matter
[23:01:27 CET] <kepstin> (this depends mostly on the container)
[23:01:31 CET] <GyrosGeier> hmm
[23:01:38 CET] <kepstin> i'd expect h264 in mpeg-ts to generally be correct.
[23:01:40 CET] <GyrosGeier> -vf repeatfields doesn't help
[23:02:05 CET] <alexpigment> kepstin: i mean if you think it's a big enough deal to investigate ffmpeg, i'd be happy to send samples
[23:02:06 CET] <GyrosGeier> also, the output codec complains
[23:02:07 CET] <GyrosGeier> [libx264 @ 0x557f3d763f00] interlace + weightp is not implemented
[23:02:15 CET] <alexpigment> GyrosGeier: that's ignorable
[23:02:28 CET] <alexpigment> it always says that for H.264 interlaced encoding
[23:02:32 CET] <JEEB> alexpigment: if you have samples where metadata is read incorrectly that's worth it
[23:02:40 CET] <GyrosGeier> Past duration 0.999992 too large   46272kB time=00:05:47.77 bitrate=1089.9kbits/s speed=4.25x
[23:02:43 CET] <GyrosGeier>     Last message repeated 84 times
[23:02:46 CET] <kepstin> alexpigment: ffmpeg is just telling you what the files say, and mpeg container poorly specified the aspect ratio field. so a lot of writing software gets it wrong.
[23:02:46 CET] <GyrosGeier> the repeat counts got smaller
[23:02:49 CET] <alexpigment> JEEB: well, until a few minutes ago, i didn't have any reason to think that the metadata was incorrect
[23:02:51 CET] <JEEB> I think the only case where I've had aspect ratio read wrong were some funky MXF files
[23:02:54 CET] <GyrosGeier> before it was ~260
[23:03:11 CET] <JEEB> MPEG-PS/TS I've had noted right so far
[23:03:21 CET] <kepstin> I have a few blu-rays with SD content (h264 in mpeg-ts), I should check those.
[23:03:33 CET] <alexpigment> JEEB: when you encode to another format (e.g. h.264), ffmpeg is saying it's 10:11 for NTSC?
[23:03:48 CET] <kepstin> but yes, I've almost always seen mpeg-ps (vob files from dvds) with incorrect values.
[23:03:50 CET] <JEEB> alexpigment: oh is this the "analogue" aspect ratios thing?
[23:04:20 CET] <JEEB> like 16:11 for PAL 16:9
[23:04:23 CET] <JEEB> (SAR)
[23:04:25 CET] <kepstin> JEEB: yep, alexpigment has some files which are 720x480 but marked with a display aspect of 4:3.
[23:04:46 CET] <JEEB> uhh
[23:04:55 CET] <JEEB> there's SD NTSC content just fine?
[23:05:04 CET] <JEEB> that is 4:3 (DAR?)
[23:05:26 CET] <kepstin> ntsc sd 4:3 content has a sar of 10/11, so 720x480 is very slightly wider than 4:3
[23:05:28 CET] <JEEB> as I think you're not talking about 40:33 SAR being incorrectly reported as 4:3?
[23:05:53 CET] <kepstin> but this file is mistagged as 8/9 sar = 4/3 dar
[23:05:53 CET] <GyrosGeier> there are probably some in-game cutscene movies in 720x480 4:3
[23:06:02 CET] <JEEB> right
[23:06:23 CET] <JEEB> the problem with DVDs is that they don't have exact aspect ratios, same for normal MPEG-PS/TS I think
[23:06:32 CET] <JEEB> the aspect ratio flag just says "16:9" or "4:3" IIRC
[23:06:39 CET] <JEEB> only with H.264 you got the parameter sets' proper values
[23:06:47 CET] <JEEB> where people started flagging the correct values
[23:07:04 CET] <alexpigment> sorry, back. anyway, i just now remember something i ran into a while back where if i didn't specify an output aspect ratio of 4:3, the result would be slightly off. maybe this whole 8:9 thing is an ffmpeg bug and i was just working around it
[23:07:20 CET] <GyrosGeier> kepstin, can this still be improved if -vf repeatfields doesn't solve the "Past duration" problem?
[23:07:24 CET] <alexpigment> (testing)
[23:07:39 CET] <JEEB> if it's the "analogue" aspect ratios for SD then that's kind of a problematic thing
[23:07:52 CET] <kepstin> GyrosGeier: you can explicitly tell ffmpeg to do vrf output with the option "-vsync 0" - might help
[23:08:10 CET] <JEEB> I thought VFR was by default :P
[23:08:18 CET] <JEEB> only with containers that can't do VFR does it duplicate/cut
[23:08:19 CET] <alexpigment> JEEB: all of these are digital sources. not sure if that is what you're talking about
[23:08:44 CET] <kepstin> alexpigment: modern digital video equipment still follows the old analogue standards.
[23:08:50 CET] <kepstin> as close as possible
[23:09:15 CET] <alexpigment> well, lemme know what happens with that m2ts file you were talking about earlier
[23:09:20 CET] <JEEB> alexpigment: things that are (on paper) mostly utilized for things that came from old digitizations (such as DVD and SD BD for example) utilize somewhat different aspect ratios
[23:09:21 CET] <alexpigment> i'm happy to provide samples as necessary
[23:09:42 CET] <JEEB> I can't link you the BD spec that says them explicitly but you'll have to trust me that these values noted here are correct
[23:09:46 CET] <JEEB> http://www.x264bluray.com/home/480p-ntsc
[23:09:48 CET] <JEEB> http://www.x264bluray.com/home/576p-pal
[23:09:57 CET] <alexpigment> JEEB: no worries. i'm just saying that ffmpeg is saying 8:9
[23:10:04 CET] <alexpigment> i don't distrust anyone
[23:10:18 CET] <kepstin> alexpigment: you should distrust your files and just manually set the sar to fix it :)
[23:10:18 CET] <JEEB> 8:9 what?
[23:10:23 CET] <alexpigment> it's just that i cannot find a single 720x480 NTSC 4:3 video that ffmpeg doesn't report as 8:9 SAR
[23:11:06 CET] <alexpigment> so if it's suppose to be 10:11, either ffmpeg is wrong, or the entire industry is seemingly doing it wrong :)
[23:11:10 CET] <JEEB> well that is exact 4:3
[23:11:17 CET] <JEEB> which is what the flag says with MPEG-2
[23:11:28 CET] <JEEB> the problem is that with a lot of stuff that actually means something different
[23:11:43 CET] <kepstin> basically, some digital engineers decided to sample the analog signal at 13.5MHz for the 720-wide ntsc, and 12+3/11 for the 640-wide ntsc (square pixels). and so 720-wide stuff, if you multiply those fractions out, ends up being 10/11 sar compared to 640-wide stuff.
[23:11:47 CET] <JEEB> it means the values I noted in those two x264bluray links (those are simplified)
[23:12:19 CET] <alexpigment> JEEB: yes, i've been to this site many times
[23:12:33 CET] <JEEB> of course then you get headaches from people comparing DVD playback on the PS3 or something, and telling you that their DVD seems to be encoded as proper 16:9 :|
[23:13:02 CET] <JEEB> (as on a 16:9 screen the thing would get cropped otherwise)
[23:13:07 CET] <kepstin> if you see 720 or 704 wide ntsc files intended for 4:3 with a sar other than 10/11, then the files are incorrectly tagged with display aspect.
[23:13:38 CET] <JEEB> then again I have modern 16:9 DVDs where the "analog" aspect ratio gives seemingly round balls :P
[23:13:45 CET] <alexpigment> well anyway, i can confirm the issue i referenced above. a while back i noticed that things weren't exactly right with the aspect ratio when converting to h.264. so i just put -aspect 4:3 and called it a day. that's still true today. that makes me think the 8:9 is actually being used by ffmpeg, not just reported wrong
[23:14:09 CET] <kepstin> alexpigment: if you used -aspect 4:3 then you were the person who set the 8:9 dar and made the files wrong.
[23:14:14 CET] <alexpigment> no
[23:14:21 CET] Last message repeated 1 time(s).
[23:14:21 CET] <alexpigment> that's after the fact
[23:14:31 CET] <JEEB> 8:9 SAR is 4:3, the proper one :P
[23:14:32 CET] <alexpigment> i had to put -aspect 4:3 in the output settings to correct the aspect ratio issue
[23:14:39 CET] <JEEB> with 720x480
[23:14:47 CET] <JEEB> the analogue one is different
[23:15:06 CET] <JEEB> now, if you master BDs at least there the SD BDs' aspect ratio is defined
[23:15:18 CET] <alexpigment> i have some blu-ray sd material
[23:15:24 CET] <alexpigment> confirming with that. 1 minute
[23:15:37 CET] <JEEB> it should give the same SAR value as on x264bluray.com
[23:15:42 CET] <JEEB> if it's H.264
[23:15:50 CET] <kepstin> hmm, I have my bd stuff on an online HD, I should check it too
[23:15:57 CET] <JEEB> if it's MPEG-2 Video you only have non-exact aspect ratios
[23:15:58 CET] <kepstin> I can never remember which m2ts on this disk was SD tho
[23:16:12 CET] <JEEB> which is the problem, as the field just says "16:9" or "4:3"
[23:16:15 CET] <alexpigment> it says 8:9
[23:16:21 CET] <JEEB> huh
[23:16:25 CET] <JEEB> mpeg-2 video or H.264
[23:16:45 CET] <alexpigment> mpeg-2 in thise case
[23:16:49 CET] <JEEB> ok, yes
[23:16:51 CET] <alexpigment> i can find some h.264 sd blu-ray stuff though
[23:16:53 CET] <alexpigment> lemme look around
[23:17:04 CET] <JEEB> that will get assigned that because the field is called "4:3"
[23:17:15 CET] <JEEB> it's context dependant :P
[23:17:27 CET] <JEEB> which sucks, really
[23:17:53 CET] <kepstin> but "4:3" on a 720 or 704 wide ntsc mpeg-2 file means you're supposed to infer that it's 10/11 sar. I wonder how much it would break if we added some heuristics to fix that in ffmpeg?
[23:18:14 CET] <JEEB> yes, I have wondered that too
[23:18:34 CET] <JEEB> at least most people will ?!?!?! since they don't know about the "analog" aspect ratios
[23:18:36 CET] <alexpigment> ok, so 720x480 AVC encoded blu-ray stuff reports 10:11
[23:18:44 CET] <kepstin> blah, my blu-ray has the sd stuff in mpeg2
[23:18:44 CET] <JEEB> yes, because AVC has a proper aspect ratio field
[23:19:00 CET] <alexpigment> kepstin: can you at least confirm the 8:9 thing?
[23:19:10 CET] <JEEB> with mpeg-2 video there's no question
[23:19:12 CET] <alexpigment> just so we can get off the "this is right" convo :)
[23:19:13 CET] <JEEB> as I've noted X times already
[23:19:20 CET] <kepstin> yes, ffmpeg is printing the incorrect aspect ratio from the mpeg2 video files.
[23:19:28 CET] <alexpigment> JEEB: no worries. just trying to settle that part of the discussion so it doesn't come up again
[23:19:33 CET] <JEEB> "incorrect" in the context
[23:19:47 CET] <JEEB> the darn field is "4:3" which is how FFmpeg interprets it without context
[23:19:50 CET] <JEEB> :D
[23:20:19 CET] <kepstin> yes, given that I know this particular case is ntsc analogue video captured as 720x480, I know that it's incorrect.
[23:20:27 CET] <alexpigment> well, i do have a recorder box (Hauppauge HD PVR 2), which doesn't seem to right to the field you refer to, so it gets treated as 8:9 as well
[23:20:29 CET] <JEEB> or it comes from a media
[23:20:39 CET] <alexpigment> brb
[23:20:41 CET] <JEEB> which is specified as the analog aspect ratios
[23:20:48 CET] <JEEB> so it's basically context-based information
[23:20:49 CET] <kepstin> alexpigment: the hauppauge stuff generally writes mpeg2 in mpeg-ts, so it's the same problem again.
[23:21:00 CET] <alexpigment> kepstin: no, it's H.264
[23:21:09 CET] <alexpigment> but yes, in mpeg-ts
[23:21:19 CET] <JEEB> H.264 has the aspect ratio in parameter sets
[23:21:25 CET] <JEEB> there's exactly zero reason to write it incorrectly
[23:21:28 CET] <JEEB> since the value is exact
[23:21:31 CET] <JEEB> unlike mpeg-2 video
[23:21:35 CET] <kepstin> oh, the HD capture? it's just streaming the stuff off-air as it received over atsc (in NA)
[23:21:44 CET] <alexpigment> no
[23:21:47 CET] <alexpigment> it's recording from HDMI
[23:21:56 CET] <alexpigment> HDMI in > H.264 hardware encoder > computer
[23:21:59 CET] <kepstin> ok, so HDMI is another mess
[23:22:17 CET] <kepstin> there's some HDMI specs that say 720x480 *is* actually 4:3
[23:22:23 CET] <JEEB> yes
[23:22:28 CET] <GyrosGeier> [libx264 @ 0x557de7208f00] non-strictly-monotonic PTS
[23:22:29 CET] <kepstin> but other devices assume it matches the old analogue specifications
[23:22:48 CET] <kepstin> most dvd players will output 720x480 as if it was 10/11
[23:23:04 CET] <kepstin> but if your capture card used the other spec, it might record as 8/9
[23:23:06 CET] <alexpigment> kepstin: like i was saying earlier, you *can* write to the other 16 pixels for 4:3 720x480. just that most people don't (and shouldn't)
[23:23:18 CET] <JEEB> that's not the point
[23:23:25 CET] <JEEB> the point is that H.264 has an exact aspect ratio field
[23:23:33 CET] <JEEB> so if something wrote 4:3 that is supposed to be 4:3
[23:23:34 CET] <JEEB> pronto
[23:23:53 CET] <JEEB> with mpeg-2 video the field is context sensitive, unfortunately
[23:24:07 CET] <kepstin> 704 and 720 are captured from analogue at the same luma sampling rate, and therefore should have the same sar, for equipment that is compatible with the analogue specs.
[23:24:10 CET] <JEEB> because they didn't have a freeform field
[23:24:26 CET] <JEEB> or maybe they  did, but people went stupid
[23:24:40 CET] <JEEB> in any case, MPEG-2 Video -> context sensitive , AVC -> not context sensitive
[23:24:47 CET] <kepstin> I think with mpeg2 you can write correct values if you fiddle with the fields in strange ways.
[23:25:01 CET] <kepstin> but the default presets just list 4:3 and 16:9 basically
[23:25:07 CET] <JEEB> yup
[23:26:10 CET] <JEEB> alexpigment: but yea - the end result is that FFmpeg is reading the aspect ratio field correctly, *but* lacks the possible context dependent logic as it expects values to be exactly what it says on the tin
[23:26:43 CET] <alexpigment> JEEB: well, in the absence of context, maybe it should default to assuming 10:11?
[23:27:12 CET] <alexpigment> again, i went through tons of files from different sources, only the blu-ray sourced h.264 video said 10:11
[23:27:43 CET] <JEEB> that just means that someone actually flagged them as 4:3 DAR
[23:27:54 CET] <JEEB> and if the content is not such then the flag is INCORRECT
[23:28:16 CET] <JEEB> and yes, the BD spec requires you to use the exact value (for a reason)
[23:28:19 CET] <alexpigment> it feels like you're doing a 180, but i think instead there's a communication issue here
[23:28:27 CET] <JEEB> no I don't
[23:28:40 CET] <JEEB> the one where there's context based decision making included is MPEG-2 VIDEO
[23:28:43 CET] <JEEB> MPEG-2
[23:28:45 CET] <JEEB> CAPISCI?
[23:28:48 CET] <alexpigment> right
[23:28:50 CET] <JEEB> H.264 is not affected
[23:29:00 CET] <JEEB> it has EXACT VALUES and YOU ARE SUPPOSED TO TAKE THEM AT FACE VALUE
[23:29:00 CET] <alexpigment> i've got lots of H.264 that *is*
[23:29:03 CET] <alexpigment> ok
[23:29:08 CET] <alexpigment> i'll drop it
[23:29:11 CET] <JEEB> so if something wrote 4:3 DAR
[23:29:16 CET] <JEEB> it is 4:3 DAR
[23:29:21 CET] <JEEB> unlike mpeg-2 video
[23:29:22 CET] <alexpigment> this was a tangent anyway while we were talking to gyros
[23:29:35 CET] <JEEB> I hope the point came through, though?
[23:29:40 CET] <alexpigment> no, it didn't
[23:29:42 CET] <JEEB> with mpeg-2 video there might be leeway for FFmpeg to fix it
[23:29:50 CET] <alexpigment> it seems like you could default to 10:11 for mpeg2
[23:29:52 CET] <JEEB> If and only if there's some context available
[23:29:56 CET] <alexpigment> but somehow that doesn't work, and i don't understand.
[23:30:00 CET] <alexpigment> and at this point, i don't care
[23:30:23 CET] <JEEB> no, I didn't say it doesn't work - I am just not capable of saying if it would work with everything with such a casee
[23:30:44 CET] <JEEB> the only thing I tried to then really note is that with H.264 this context-dependant thing doesn't exist
[23:30:45 CET] <alexpigment> cool. i'm done with the convo
[23:31:01 CET] <JEEB> since all related specifications tell you to utilize the exact values, which are available
[23:31:04 CET] <JEEB> ok
[23:31:07 CET] <JEEB> it seems like I'm really bad at explaining
[23:31:08 CET] <JEEB> sorry
[23:31:12 CET] <JEEB> (´4@)
[23:31:50 CET] <JEEB> mpeg-2 video -> there could be changes made but it's so context dependant that I am not sure if it should be the API client or the FFmpeg itself to do the decision
[23:31:57 CET] <alexpigment> it's ok. it just came up because kepstin thought it was weird that a video was being reported as 8:9. and i see that number every day, so *not weird to me!*. i don't really care about it, since it doesn't affect me in any meaningful way
[23:32:01 CET] <JEEB> h.264 -> no context dependant stuff
[23:32:10 CET] <kepstin> conclusion: when mpeg2 was made, computer video was a mess, and the aspect ratio stuff poorly specified. WHen h264 was made, the aspect ratio field actually works correctly. There's a lot of legacy or converted (without correction) content around
[23:32:54 CET] <kepstin> and either way, the difference is only about 3%, and if your 720 frames have content right to the edge (no black bars), people probably won't notice
[23:33:38 CET] <JEEB> yup
[23:36:50 CET] <GyrosGeier> hmm, encoding output looks good
[23:37:01 CET] <GyrosGeier> thanks kepstin and alexpigment
[23:37:23 CET] <GyrosGeier> one last thing: the PS has closed captions, can I convert these to mkv subtitles?
[23:37:57 CET] <JEEB> if it's the US captions you will have fun with that
[23:38:18 CET] <JEEB> (mostly because the darn things are in the video track)
[23:38:41 CET] <GyrosGeier> the shiny blinky bits at the top?
[23:38:42 CET] <JEEB> you will receive a side data packet
[23:39:02 CET] <JEEB> they used to be in the video frame but now they're just as additional packets in the video track
[23:39:12 CET] <alexpigment> GyrosGeier: hmmm, i've never thought about if there's a way to convert those
[23:39:24 CET] <GyrosGeier> stackoverflow says [out+subcc]
[23:39:26 CET] <alexpigment> i just always crop and pad as necessary
[23:39:33 CET] <JEEB> GyrosGeier: that's the ffmpeg.c way
[23:39:40 CET] <JEEB> I thought you were using the API
[23:39:48 CET] <JEEB> so I started explaining how to generate the new track
[23:39:49 CET] <JEEB> :)
[23:40:09 CET] <GyrosGeier> JEEB, I'm on the command line
[23:40:18 CET] <JEEB> yea then there's probably some way to get them
[23:40:24 CET] <GyrosGeier> just ripping all my DVDs and the older BluRays
[23:40:31 CET] <JEEB> I've only seen them extracted through the API with mpv
[23:40:52 CET] <alexpigment> that could be a fun project for someone... ;)
[23:40:54 CET] <JEEB> (find side data, create a new track on your side, open a new decoder and feed it the side data packets)
[23:42:07 CET] <GyrosGeier> with [out+subcc], I don't get an audio stream
[23:42:23 CET] <JEEB> did you select your audio stream?
[23:42:30 CET] <JEEB> if you do a -map all automatic stream selection goes away
[23:42:44 CET] <GyrosGeier> no -map
[23:42:56 CET] <JEEB> uhh, can you post what you tried then on pastebin or so? :P
[23:43:10 CET] <GyrosGeier> ffmpeg -f lavfi -i 'movie=stream.dump[out+subcc]' -vsync 0 -c:v libx264 -crf 24 -flags +ildct+ilme ~/Sir_No_Sir.mkv
[23:43:18 CET] <JEEB> right
[23:43:20 CET] <JEEB> lavfi input
[23:43:37 CET] <GyrosGeier> I get a video and a subtitle (ass) stream
[23:44:09 CET] <JEEB> you will probably want to add another input with your original input
[23:44:18 CET] <JEEB> and then map things from the first and second as needed
[23:44:33 CET] <JEEB> (probably video and audio from the original input, and then subtitles only from the lavfi inpu
[23:44:52 CET] <GyrosGeier> ah
[23:46:14 CET] <GyrosGeier> ffmpeg -i stream.dump -f lavfi -i 'movie=stream.dump[out+subcc]' -vsync 0 -c:v libx264 -crf 24 -flags +ildct+ilme ~/Sir_No_Sir.mkv
[23:46:17 CET] <GyrosGeier> that looks good
[23:46:51 CET] <GyrosGeier> okay, finishing touch: add language tags to audio and subtitles
[23:47:20 CET] <alexpigment> -metadata:s:a:0 language=eng
[23:47:28 CET] <alexpigment> or whatever the language is
[23:47:47 CET] <alexpigment> then i think you can also do -metadata:s:s:0 language=eng  (correct me if i'm wrong on that)
[23:48:02 CET] <JEEB> I think that should be correct
[23:48:09 CET] <JEEB> metadata mapped on stream, subtitle, 0th
[23:48:35 CET] <alexpigment> https://en.wikipedia.org/wiki/List_of_ISO_639-2_codes <-- here are the language codes
[23:49:44 CET] <GyrosGeier> yup
[23:50:34 CET] <GyrosGeier> hmm
[23:51:20 CET] <GyrosGeier> the "[libx264 @ 0x55c64bdd1560] non-strictly-monotonic PTS" appears right where it started complaining about the "Past duration"
[23:51:31 CET] <GyrosGeier> so I guess that is gone now too
[23:51:32 CET] <alexpigment> oh that ol' gem
[23:51:48 CET] <alexpigment> i can't recall exactly what that is, but i've been seeing it from time to time lately
[23:51:59 CET] <alexpigment> the others here probably know what it is and why
[23:52:09 CET] <JEEB> it's that your PTS aren't going forward well enough :P
[23:52:13 CET] Action: kepstin has explained it before
[23:52:31 CET] <alexpigment> yeah, i'm getting deja vu, so you probably explained it yesterday
[23:52:52 CET] <kepstin> it means that ffmpeg thinks that at some point in the stream the video should be cfr, but the frame timestamps are too close together for the cfr rate
[23:53:01 CET] <kepstin> iirc, this is done at the end of the filter chain
[23:53:33 CET] <alexpigment> is it ingorable?
[23:53:42 CET] <JEEB> umm, it doesn't have too much to do with CFR
[23:53:48 CET] <kepstin> not always. it indicates that frames are being dropped
[23:53:56 CET] <JEEB> umm
[23:53:58 CET] <JEEB> that got to libx264
[23:54:15 CET] <JEEB> so it clearly went through ffmpeg.c
[23:54:17 CET] <kepstin> oh, i'm talking about the Past duration error
[23:54:21 CET] <JEEB> right
[23:54:28 CET] <alexpigment> haha
[23:54:29 CET] <JEEB> I was talking about the non-strictly monotonic PTS
[23:54:33 CET] <alexpigment> yes, new topic ;)
[23:54:56 CET] <JEEB> the past duration message usually has some specifics there but can get overwritten on the terminal by some new messages :P
[23:55:10 CET] <kepstin> hmm, that reminds me, I should fix the concat filter so it doesn't give past duration errors when the second file is higher framerate than the first
[23:55:26 CET] <GyrosGeier> I suspect that the timestamps in the PS are just discontinuous because someone spliced together two PS streams without adjusting the timestamps, and if you try to fix it, you introduce more errors
[23:55:32 CET] <alexpigment> kepstin: does that apply to VFR video?
[23:55:46 CET] <kepstin> concat filter copies the framerate from the first file, indicating cfr if the first file is cfr, so if the second file is different then you get that message
[23:56:15 CET] <alexpigment> i'm just wondering if you'd run into that when concat'ing two VFR files, and just incidentally one is higher than the other
[23:56:34 CET] <alexpigment> i don't think i've ever tried to concat two files with obviously different frame rates, but i've seen the message in question
[23:56:35 CET] <JEEB> also man, ffmpeg.c's "vsync" code
[23:56:41 CET] <JEEB> I do not want to look at that stuff again
[23:56:48 CET] <kepstin> alexpigment: if the first file is correctly detected as vfr, and therefore has the value '0/1' in the framerate field, then concat will output vfr and it'll work.
[23:56:52 CET] <JEEB> so many if/elses
[23:57:08 CET] <alexpigment> i see
[23:57:23 CET] <kepstin> because concat simply copies the framerate from the first file to the output
[23:57:37 CET] <JEEB> it's always the best feeling when lavf/lavc give you correct timestamps
[23:57:47 CET] <JEEB> and then ffmpeg.c proceeds to murder it with vengeance
[23:57:49 CET] <GyrosGeier> aren't there "absolute" timestamps in PS normally?
[23:57:52 CET] <kepstin> I have a half-done patch to fix it by checking that all the files are the same framerate, and then either using that in the output or setting it to vfr if any are different.
[23:58:57 CET] <JEEB> anyways, I should post a patch to make at least mpeg-ts demuxer to be able to handle wrap-arounds by itself
[23:58:59 CET] <GyrosGeier> at least I remember that when I decode DVB, I get the current time minus 6 hours shown as current position (presumably because the station restarts the encoder at 6 AM)
[23:59:06 CET] <JEEB> having the clients always handle it is :|
[23:59:23 CET] <JEEB> GyrosGeier: doesn't necessarily mean encoder start but just the last wrap-around )
[23:59:26 CET] <JEEB> :)
[23:59:38 CET] <JEEB> 33bit integer and the time base is 90000
[23:59:38 CET] <GyrosGeier> hmm
[23:59:50 CET] <JEEB> (yes, 33bit - I didn't write that wrong)
[00:00:00 CET] --- Wed Jan 24 2018