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

[burek]

[00:02:12 CEST] <cehoyos> JEEB: For dst, this is not a question of the "information", our decoder provides the audio with this sample rate (which is different from the one in the white paper or advertising), it cannot be changed. The same is true for some SBR files.
[00:04:08 CEST] <JEEB> yes
[00:04:16 CEST] <JEEB> I was mostly just responding to the question asked
[00:04:38 CEST] <JEEB> regarding a decoder showing the wrong rate after probe() was done
[00:05:00 CEST] <JEEB> dst is of course its own bundle of fun :)
[00:05:00 CEST] <cehoyos> I finally realize there is a usecase for mediainfo ;-)
[00:05:15 CEST] <cehoyos> (Or a fundamental problem about ffprobe)
[00:15:28 CEST] <garyserj> I have two mp4 files, I made examples files, each one second. One uploads to youtube, one does not.  If I look at the profile of each on mediainfo, I see that the bad one has encoding settings and writing library, and the good one does not.  I am able to import the bad one into movie maker, and save it, and it becomes good, and has no encoding settings or writing library listed by mediainfo.
[00:15:28 CEST] <garyserj> I'd like to do that with ffmpeg though. How can I do that?   this is the profile of the bad mp4 https://pastebin.com/raw/XD5YnaLg  and this is the profile of the good mp4 https://pastebin.com/raw/b5xqFLxy
[00:16:43 CEST] <JEEB> garyserj: neither of those flags most likely has anything to dow ith whether youtube takes it in or not
[00:16:53 CEST] <JEEB> otherwise everyone would have to run a patched libx264
[00:17:24 CEST] <cehoyos> garyserj: Instead please provide the command line that you used to produce the "bad" file together with the complete, uncut console output.
[00:19:10 CEST] <garyserj> cehoyos: ok that will take a while.. i'll reply when done!
[00:25:40 CEST] <Atlenohen> standby ... will report findings soon
[00:33:21 CEST] <garyserj> thanks for waiting. here is the output of mp4 that won't upload to youtube https://pastebin.com/raw/9ap6bMfe
[00:33:51 CEST] <JEEB> > 1348290000.00 tbn
[00:34:07 CEST] <JEEB> this sounds like something that might cause issues down the line if it gets written into the output container
[00:35:47 CEST] <garyserj> a)what does it mean b)movie maker was able to import the file and save it and the saved file uploaded to youtube. How might I 'fix' it witih ffmpeg like movie maker did?
[00:36:27 CEST] <JEEB> well if it decoded and re-encoded your thing it most likely limited the time base, while somehow ffmpeg.c ended up with a humongous time base there
[00:36:55 CEST] <JEEB> given that the input time base is 90k it sounds funky at the very least
[00:37:43 CEST] <garyserj> so is there a flag in ffmpeg to limit the timebase or is this a  bug in ffmpeg that has no flag to fix?
[00:37:50 CEST] <garyserj> (or both)
[00:39:16 CEST] <JEEB> I would first check a newer version of FFmpeg
[00:39:21 CEST] <JEEB> since you're on 3.4
[00:39:32 CEST] <JEEB> you can find current master builds from zeranoe's for example
[00:40:38 CEST] <garyserj> another odd thing is I reckon the phone i recorded the 3gp on has been oriented the correct way, yet some videos come out needinig a vflip and some needing a -vf "transpose=1" (clockwise 90 degree turn), and most don't need any turn or flip
[00:40:44 CEST] <garyserj> this one didn't need any turn or flip
[00:41:31 CEST] <JEEB> mobile camera stuff is fun :P
[00:41:52 CEST] <garyserj> I can understand the case of vflip 'cos maybe it's possible i oriented my rectangular phone the wrong way. but 90 degrees is very strange 'cos  don't place my camera on one of its  small edges
[00:42:04 CEST] <garyserj> 'cos don't = 'cos I  don't
[00:42:16 CEST] <JEEB> yea but the software might still think you're in some other mode
[00:42:21 CEST] <JEEB> fun for the whole family
[00:42:36 CEST] <JEEB> of course, I'm just guesstimating without knowing more about it
[00:43:48 CEST] <JEEB> also the weird time base is probably due to the content being of non-constant rate (mobile phones generally tend to record "as fast as possible with a cap". so you might be hitting that cap (say, 30Hz) or something lower than that
[00:43:59 CEST] <JEEB> although I'm just guesstimating without knowing the details
[00:44:33 CEST] <garyserj> zeranoe has 'builds' i'm just downloading one it's about 60MB!
[00:45:20 CEST] <cehoyos> I suspect the input file is vfr, I suggest you force an output frame rate with "-r 30000/1001"
[00:45:31 CEST] <cehoyos> This will force a sane time base
[00:45:56 CEST] <JEEB> yes, that is what I was alluding to with the long and winding explanation about mobile phone cameras recording at a non-static rate :)
[00:46:07 CEST] <JEEB> "as fast as possible, with a cap" basically
[00:46:07 CEST] <cehoyos> Yes, I hadn't read so far, sorry
[00:46:29 CEST] <JEEB> although it's still weird so it would be interesting to know if current master handles it any better
[00:46:46 CEST] <JEEB> and considering the input has 90k time base for the stream, it's kind of weird how it goes worse from that
[00:46:47 CEST] <cehoyos> But thank you for proving that "complete, uncut console output missing" is still the key to such issues;-)
[00:46:59 CEST] <JEEB> often it is :)
[00:47:05 CEST] <JEEB> sometimes you end up needing a bit more
[00:47:21 CEST] <cehoyos> I don't really expect it to work better but a test won't hurt.
[00:47:32 CEST] <cehoyos> garyserj: Feel free to provide the input sample
[00:47:35 CEST] <JEEB> yea, I don't think the code around there changed too much
[00:47:47 CEST] <JEEB> but since there are binaries available, the test shouldn't take too long :)
[00:47:57 CEST] <cehoyos> True!
[00:48:19 CEST] <JEEB> also funny enough there should be a time base option both in ffmpeg.c as well as in movenc.c
[00:48:28 CEST] <JEEB> so in theory one could set it to the input time base (90k)
[00:48:31 CEST] <JEEB> to get a similar result
[00:49:27 CEST] <cehoyos> Maybe "-r 24000/1001": Check if many frames are dropped with this value
[00:49:47 CEST] <cehoyos> I think the correct solution is to force a sane frame rate
[00:50:39 CEST] <JEEB> I would think a similar time base should most likely work (since 90k is used in mpeg-ts and youtube has to be taking in content straight from these devices). but yes, either vf fps=30000/1001 or -r 30000/1001 should make sure the output is of constant rate :)
[00:51:05 CEST] <JEEB> (the options in ffmpeg.c are -time_base and -enc_time_base btw)
[00:51:46 CEST] <JEEB> movenc.c has video_track_timescale AVOption
[00:51:51 CEST] <JEEB> just for the record :)
[00:52:27 CEST] <garyserj> https://pastebin.com/raw/7dTEv0by
[00:52:50 CEST] <JEEB> garyserj: thanks. so yea, the logic that leads to that value is still there :)
[00:53:32 CEST] <JEEB> if you are re-encoding you might attempt what cehoyos noted regarding setting output rate of 30000/1001
[00:53:39 CEST] <JEEB> which is seemingly the cap in your sample
[00:54:11 CEST] <JEEB> or then if you don't want to do that, you can attempt setting the time bases for that output stream. setting the frame rate is simpler
[00:54:32 CEST] <JEEB> and if you could share the sample, that could be lovely
[00:54:32 CEST] <garyserj> okay, i'm an ignoramous with ffmpeg, what'd be the flag for that?  And what might movie maker be using if not ffmpeg?
[00:54:50 CEST] <JEEB> no idea, and it might be forcing the rate by default
[00:54:58 CEST] <JEEB> since usually video editors don't output variable frame rate
[00:55:03 CEST] <JEEB> (even if the input is)
[00:55:39 CEST] <garyserj> so i guess i'd need the flag for setting a set frame rate
[00:56:03 CEST] <garyserj> is that a 'no dea' for the second question only?
[00:56:11 CEST] <garyserj> (sorry, my 'i' key is rubbish)
[00:56:22 CEST] <garyserj> dea=idea
[00:56:40 CEST] <JEEB> the no idea is regarding whether the thing you're talking about is also using FFmpeg in some capacity
[00:56:58 CEST] <garyserj> i'd assume not
[00:57:08 CEST] <garyserj> but i'm wondering what alternatives there are that software uses
[00:57:11 CEST] <cehoyos> Didn't I already provide the missing "flags"?
[00:57:24 CEST] <garyserj> ah ok
[00:57:27 CEST] <JEEB> and setting a video frame rate can be done in two ways. either -r "30000/1001" or -vf "fps=fps=30000/1001"
[00:57:42 CEST] <cehoyos> Actually not
[00:57:53 CEST] <garyserj> cehoyos: yeah -r 30000/1001
[00:57:56 CEST] <JEEB> you did note the rate setting twice :)
[00:57:58 CEST] <cehoyos> The second variant won't tell you if it wasn't necessary to choose such a high value
[00:58:34 CEST] <cehoyos> Look at "dups", if it increases constantly, choose a lower number
[00:58:39 CEST] <garyserj> okay i will try that
[00:58:45 CEST] <JEEB> also the 90k time base seems to be a common thing with android
[00:58:50 CEST] <JEEB> my sample from last year has that too
[00:58:57 CEST] <cehoyos> If it only duplicates for the first second(s) and then stays (nearly) constant, the value is ok
[01:00:55 CEST] <garyserj> https://pastebin.com/raw/zrzkSJnA
[01:01:24 CEST] <JEEB> my sample ends up with "only" 22500 AVStream time_base :)
[01:01:33 CEST] <garyserj> ah the file example is only one second long. But the problem exists for a three second file too or for larger
[01:01:55 CEST] <cehoyos> Remove "-t 1"
[01:02:07 CEST] <garyserj> how many seconds do you need?
[01:02:16 CEST] <cehoyos> Yes but with the one second sample you don't know a useful value for -r.
[01:02:27 CEST] <cehoyos> As many as your input has
[01:02:53 CEST] <cehoyos> You can use "-f null -" instead of "-vcodec libx264 outputfilename.mp4"
[01:02:57 CEST] <garyserj> okay! i'll just remove the -ss and -t completely. this will take longer.
[01:03:00 CEST] <cehoyos> To speed up the process
[01:03:03 CEST] <cehoyos> If you need
[01:03:44 CEST] <garyserj> and isntead of -acodec i guess?
[01:03:58 CEST] <garyserj> so no vcodec no acodec no output filename but -f null -
[01:04:56 CEST] <garyserj> and i guess i keep the -r "30000/1001"
[01:04:57 CEST] <cehoyos> "ffmpeg -i input -acodec copy -r 30000/1001 -f null -"
[01:05:08 CEST] <garyserj> ffmpeg -i Apr__8_2019_WLC_C_3.3gp -f null - -r "30000/1001"
[01:05:13 CEST] <cehoyos> No
[01:05:41 CEST] <cehoyos> ffmpeg -i Apr__8_2019_WLC_C_3.3gp -acodec copy -r 30000/1001 -f null -
[01:05:55 CEST] <JEEB> yea, the remux-only -r patch I think is still on the ML
[01:06:56 CEST] <cehoyos> It wouldn't help
[01:06:57 CEST] <garyserj> I am getting a lot of lines like [null @ 00000000004b8fc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 6443 >= 6443   and each time the number increases   I will show the full output on pastebin link
[01:07:28 CEST] <JEEB> cehoyos: yea it would just break the A/V sync of VFR input :)
[01:08:46 CEST] <garyserj> https://pastebin.com/raw/EnxTqCJv
[01:09:14 CEST] <cehoyos> Sorry, the command was wrong;-(
[01:09:33 CEST] <cehoyos> Should have been: ffmpeg -vsync cfr -i Apr__8_2019_WLC_C_3.3gp -acodec copy -r 30000/1001 -f null -
[01:09:42 CEST] <cehoyos> But don't worry, we can calculate the issue...
[01:09:57 CEST] <garyserj> ok, running now, thanks
[01:10:43 CEST] <cehoyos> 30000/1001 is correct
[01:10:46 CEST] <garyserj> https://pastebin.com/raw/GgECKThL
[01:11:17 CEST] <cehoyos> The device just needed to "warm up", it could then keep the high framerate
[01:12:00 CEST] <cehoyos> I wonder if it is a bug that ffmpeg is trying to produce vfr output with "-r"...
[01:12:13 CEST] <cehoyos> May be a regression
[01:12:15 CEST] <JEEB> quite possible
[01:12:22 CEST] <cehoyos> Sounds like one to me
[01:13:06 CEST] <garyserj> heh, sounds like a star trek conversation ;-)
[01:15:01 CEST] <garyserj> good stuff. hmm , I can't see an 'issues' section on the ffmpeg github page
[01:15:10 CEST] <garyserj> I see bug reports link n topic, i'll check there
[01:16:45 CEST] <cehoyos> Why are you interested in that topic if I may ask?
[01:17:20 CEST] <cehoyos> To quote myself: Feel free to provide a sample...
[01:17:27 CEST] <garyserj> well, if there's a bug in ffmpeg then I want to help resolve it
[01:17:36 CEST] <cehoyos> Feel free to provide a sample
[01:17:41 CEST] <garyserj> also sometimeis something is said that I don't understand now but understand later
[01:17:55 CEST] <JEEB> the android mp4 samples I have seem to max out in more pleasant time bases :)
[01:18:04 CEST] <JEEB> so definitely something interesting in that one
[01:19:35 CEST] <garyserj> The other 3gp files I had did upload, but is it possible they had the same issue?
[01:19:57 CEST] <garyserj> like the other 3gp files i had did convert to an mp4 that uploaded, but is it possible they had the same issue?
[01:20:23 CEST] <garyserj> i'd rather make a new video, 'cos that one did have some peoples' faces in t
[01:20:47 CEST] <garyserj> the first second didn't have anybodys' faces but seconds beyond that did
[01:21:00 CEST] <cehoyos> The first second is enough
[01:21:44 CEST] <Atlenohen>  ... Takes a bit long to make it really nice and clear ...
[01:21:58 CEST] <garyserj> ffmpeg -i -ss 0 -t 1 Apr__8_2019_WLC_C_3.3gp -acodec copy -vcodec copy sample.3gp  <-- that ok?
[01:22:03 CEST] <cehoyos> NO!!!
[01:22:03 CEST] <garyserj> ah  mean
[01:22:10 CEST] <garyserj> ffmpeg -iApr__8_2019_WLC_C_3.3gp -acodec copy -vcodec copy  -ss 0 -t 1  sample.3gp
[01:22:15 CEST] <garyserj> with space after -i
[01:22:24 CEST] <cehoyos> Either provide an input file not created with FFmpeg (!), or feel free not to provide a sample file
[01:22:32 CEST] <faLUCE> cehoyos: instead of making re-indentation on the makefiles, how should they formatted? by adding spaces?
[01:22:42 CEST] <cehoyos> Don't change it
[01:23:10 CEST] <faLUCE> cehoyos: and what if they appear badly formatted?
[01:23:21 CEST] <cehoyos> Then send a second patch that fixes the indentation.
[01:24:15 CEST] <faLUCE> uhmmm but why the indentation can't be changed in the first patch?
[01:24:16 CEST] <garyserj> okay so let's say i don't proviide a sample. Shall I just provide this line and its output ffmpeg -vsync cfr -i Apr__8_2019_WLC_C_3.3gp -acodec copy -r 30000/1001 -f null -
[01:24:37 CEST] <garyserj> What commands with output, should I provide?
[01:25:20 CEST] <garyserj> is this chat log sufficient?
[01:27:01 CEST] <garyserj> here http://ffmpeg.org/bugreports.html  they say if the sample file is too large, cut it down e.g. dd if=sample-file of=small-sample-file bs=1024 count=10000
[01:27:07 CEST] <garyserj> I can cut it down to 1 second with a line like that
[01:31:12 CEST] <cehoyos> Please do that, than test the sample (this is very important!), then provide it
[01:33:12 CEST] <cehoyos> If you decide to open a ticket (as I tried to imply, it may be better to just provide a sample), please do not share a chat log there, please do not open a ticket if you cannot provide a sample file, please test your sample file before uploading it and please don't forget to provide the command line you tested together with the complete, uncut console output, only current FFmpeg git head is supported
[01:34:07 CEST] <garyserj> ok, thanks
[01:36:47 CEST] <cehoyos> will you provide the sample now? If not, I will see the link in 24 hours
[01:37:12 CEST] <garyserj> yeah i'll provide a sample now, just running the dd command, thanks
[01:37:24 CEST] <garyserj> just fixing my path so i can run the dd command. i have some path issues!
[01:41:43 CEST] <garyserj> I just made a 1MB sample with dd, dd if=Apr__8_2019_WLC_C_3.3gp of=sample.3gp bs=1024 count=1000      And even VLC won't play it
[01:42:43 CEST] <cehoyos> You have to use tools/qt_faststart before using dd
[01:43:02 CEST] <garyserj> i've used dd before, but not that, i'll look into that
[01:43:45 CEST] <cehoyos> Just post your link here, I will see it a day later.
[01:43:50 CEST] <cehoyos> Good night
[01:43:52 CEST] <garyserj> okay, thanks
[01:43:57 CEST] <garyserj> i'll make a 100KB sample
[01:43:59 CEST] <garyserj> that's about 1 second
[01:44:14 CEST] <garyserj> without the qt.. i'll be here this week too
[01:44:24 CEST] <garyserj> gnight
[01:44:30 CEST] <garyserj> and will post here
[01:45:33 CEST] <garyserj> http://ge.tt/5JDvaYv2
[01:45:50 CEST] <garyserj> 102,400 sample1.3gp
[01:49:00 CEST] <cehoyos> How did you test the sample you uploaded?
[01:51:52 CEST] <garyserj> I haven't managed to test it yet 'cos I don't know the faststart command. And i'm not even sure how i'd test it for the timebase issue other than perhaps trying to run those commands on it and look for tb. but that's where I am at the moment.
[01:52:09 CEST] <garyserj> sorry, should've tested it but can't yet. but i wanted to make sure you had something!
[01:52:34 CEST] <garyserj> if i knew right now how to test it then i would
[01:52:43 CEST] <cehoyos> Please do not provide a sample that you didn't test and please do not open a ticket without a sample!
[01:52:53 CEST] <garyserj> okay. i haven't opened any ticket
[01:53:03 CEST] <cehoyos> (And how is all this related to faststart??)
[01:53:27 CEST] <garyserj> just that you mentioned to do qt_faststart before using dd.
[01:53:33 CEST] <garyserj> but i don't know the command to do that
[01:54:08 CEST] <cehoyos> tools/qt_faststart is a tool that you have to use before dd so that dd will not damage your file, faststart is an option for the mov (and mp4) muxer
[02:01:47 CEST] <garyserj> can anybody advise how  I can use  tools/qt_faststart ?
[02:05:23 CEST] <garyserj> ah i see it's fairly simple https://manpages.debian.org/stretch/ffmpeg/qt-faststart.1.en.html  i just gotta get the program
[02:07:43 CEST] <Atlenohen> Actually , build log proven to be useful
[02:07:49 CEST] <Atlenohen> it just takes a good peek at it
[02:09:59 CEST] <garyserj> I see it was integrated into ffmpeg
[02:18:39 CEST] <garyserj> ffmpeg -i Apr__8_2019_WLC_C_3.3gp -codec copy -movflags +faststart largefixed.3gp     Thus fixing it with  faststart. I tried dd if=largefixed.3gp of=sample2.3gp bs=1024 count=1000     It plays.
[02:18:47 CEST] <garyserj> here is the sample http://ge.tt/9CRTdYv2
[02:18:59 CEST] <garyserj> 1,024,000 sample2.3gp
[02:48:13 CEST] <Atlenohen> btw, I found YOUTUBE to be broken with MP4 faststart, or ffmpeg aint doing it right (but it is confirmed with ffprobe), so I had to use MKV for YOUTUBE
[02:51:34 CEST] <garyserj> Interestingly, when I made a sample file so dd, followed by faststart (I used the ffmpeg one), then I used the -vsync cfr line with -r ...  that was given, so I Had a sample 3gp. Then I did the command I Had done to convert to mp4, the mp4 not only played fine and not only gave no tbn issue, but also, uploaded fine to youtube.
[02:53:04 CEST] <garyserj> I mean.. When did dd followed by faststart(I used the ffmpeg one), then  i used the -vsync cfr line with -r ...  that was given, (But making a file  rather than using -f null -). Then   it played fine, gave no tbn issue , and most importantly, it uploaded fine to youtube.
[03:18:54 CEST] <HickHoward> is Dolby AC-4 worth implementing into ffmpeg?
[03:34:42 CEST] <garyserj> btw, I am not sure how I would verify the sample, but it played, and it failed to upload to youtube, so in that sense it's a good sample.
[04:17:04 CEST] <furq> HickHoward: someone will implement it when they have something they want to decode with it
[04:17:10 CEST] <furq> which is probably why nobody has done it yet
[04:21:35 CEST] <HickHoward> well this is gonna suck
[04:22:03 CEST] <HickHoward> but i don't mind waiting for that moment
[07:29:17 CEST] <Atlenohen> solved it
[07:29:20 CEST] <Atlenohen> report tomorrow, sleep
[09:01:05 CEST] <dongs> JEEB: i have it, but i donno if decrypting it was correct. you're welcoem to the sample stream tho.https://mega.nz/#!cQsw3IAZ!VN8d_QSJDH0iu4isLqtfmX5yuy9Yjl6PGeJkMtegDzY
[10:29:24 CEST] <Silicium> hi there
[10:30:53 CEST] <Silicium> i dump images from a video using image2 but i want to change the output frame integer value by 20. how can i achieve that?
[13:53:38 CEST] <howaboutsynergy> Can ffmpeg cut out multiple parts from an audio file with one command? eg. removing multiple ads
[13:54:53 CEST] <howaboutsynergy> rather than using multiple ffmpeg invocations for each part to be removed using -ss and -to
[13:54:54 CEST] <pink_mist> I would be extremely surprised if it couldn't
[13:55:09 CEST] <howaboutsynergy> ok, can you tell me how? pink_mist
[13:55:20 CEST] <pink_mist> no, if I knew how, I would have already done so
[13:55:27 CEST] <howaboutsynergy> oh, right
[13:55:30 CEST] <JEEB> you can probably do it with a filter but not with -ss / -t
[13:55:32 CEST] <pink_mist> I'd check the ffmpeg-filters man pages
[13:55:42 CEST] <howaboutsynergy> ok, let's check
[13:55:43 CEST] <JEEB> which also means that you will have to re-encode
[13:56:04 CEST] <howaboutsynergy> ohhh
[13:56:05 CEST] <pink_mist> oh, well that's a bummer
[13:56:24 CEST] <howaboutsynergy> yeah, I'd rather use multiple ffmpeg invocations than reencode
[13:56:28 CEST] <pink_mist> unless you've got a lossless stream
[13:56:44 CEST] <howaboutsynergy> nah, it's lossy
[13:57:09 CEST] <howaboutsynergy> I don't need precision though, so -c copy would od
[13:57:10 CEST] <howaboutsynergy> do*
[13:57:38 CEST] <howaboutsynergy> ok then, thanks for the help, I'll stick to -ss and -to and multiple ffmpeg runs.
[13:57:58 CEST] <howaboutsynergy> Oh, one more thing, this yields a bunch of parts, how would I merge them?
[13:58:34 CEST] <howaboutsynergy> without reencoding
[13:58:52 CEST] <howaboutsynergy> looks like $ ffmpeg -f concat -i mylist.txt -c copy output
[13:58:59 CEST] <howaboutsynergy> yes?
[13:59:42 CEST] <howaboutsynergy> I'll try
[14:00:08 CEST] <pink_mist> yeah, trying it and seeing is a great way to check if something works =)
[14:01:38 CEST] <howaboutsynergy> :D
[14:02:01 CEST] <howaboutsynergy> just wanted to make sure there wasn't a better or more idiomatic way first ;)
[14:02:42 CEST] <JEEB> you could make an app that indexes things and then processes them in one pass nicely
[14:02:47 CEST] <JEEB> but ffmpeg.c currently will not do that for you :)
[14:02:58 CEST] <JEEB> after all, ffmpeg.c cannot do everything you could do with the library
[14:03:48 CEST] <howaboutsynergy> interesting that -ss can be used on output: "When used as an output option (before an output url), decodes but discards input until the timestamps reach position.)" I wonder if this means I don't get garbled first frames in vlc
[14:04:20 CEST] <JEEB> but that only works with re-encoding
[14:04:41 CEST] <howaboutsynergy> so, you mean, not with copy?
[14:04:45 CEST] <JEEB> yes
[14:04:48 CEST] <howaboutsynergy> got it
[14:04:49 CEST] <JEEB> because you can't decode
[14:05:03 CEST] <howaboutsynergy> right
[14:05:15 CEST] <JEEB> with -c copy ffmpeg.c will use lavf seeking to guesstimate where the last random access point was
[14:05:18 CEST] <JEEB> and copies from there
[14:05:19 CEST] <howaboutsynergy> so with copy, I'm always suck with those evil video frames(when video)
[14:05:34 CEST] <howaboutsynergy> stuck*
[14:05:37 CEST] <JEEB> you shouldn't get garbled unless your input is marked incorrectly
[14:05:54 CEST] <howaboutsynergy> what do you mean by that?
[14:05:55 CEST] <JEEB> as ffmpeg.c and lavf should only seek to random access points
[14:06:08 CEST] <JEEB> you shouldn't get a stream starting at a non-RAP
[14:06:46 CEST] <howaboutsynergy> sounds like I shouldn't get garbled first frames ?
[14:06:52 CEST] <howaboutsynergy> with copy, ever
[14:07:07 CEST] <howaboutsynergy> but man ffmpeg looking at -ss kinda makes sense that I do
[14:07:08 CEST] <JEEB> I wouldn't say ever since some files are mis-marked
[14:07:23 CEST] <JEEB> but generally you shouldn't be getting them
[14:07:28 CEST] <JEEB> unless the stream is broken
[14:07:47 CEST] <howaboutsynergy> I only tested on youtube videos, downloaded with youtube-dl
[14:08:15 CEST] <howaboutsynergy> I don't remember ever not getting any bad ones
[14:08:31 CEST] <JEEB> I'm trying to remember if VP9 had something special that made cutting more problematic
[14:10:26 CEST] <howaboutsynergy> however, vlc kinda skips a bit of the beginning on any video/audio, compared to mplayer, so I don't know
[14:13:13 CEST] <JEEB> howaboutsynergy: what sort of inputs are you dealing with btw? youtube can feed you a lot of different stuff
[14:17:20 CEST] <howaboutsynergy> ah, I'm not using any youtube inputs anymore, I'm currently looking at audio mp3s from grc the Security Now shows, Stream #0:0: Audio: mp3, 44100 Hz, mono, fltp, 64 kb/s  ; So I don't remember what codecs the youtube vids were using
[14:18:05 CEST] <howaboutsynergy> I took a look at one vid: Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv, bt709), 1920x1080, SAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default)
[14:18:14 CEST] <JEEB> ok, so vp9
[14:18:19 CEST] <howaboutsynergy> Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp (default)
[14:18:26 CEST] <JEEB> I don't remember if there was some thing in VP9 that made cutting it harder
[14:18:40 CEST] <JEEB> like, that the coder state was not reset at RAPs
[14:18:51 CEST] <howaboutsynergy> no idea
[14:19:38 CEST] <JEEB> asked #elsewhere if someone would remember
[14:19:48 CEST] <JEEB> because I remember having discussions on something that slightly resembles this
[14:20:50 CEST] <howaboutsynergy> ok I actually found a cut vid which, in the beginning of the vid, garbles with vlc but not at all with mplayer
[14:21:07 CEST] <howaboutsynergy> so, I tend to believe that maybe's a vlc issue
[14:21:15 CEST] <JEEB> possible
[14:21:26 CEST] <howaboutsynergy> like: [h264 @ 0x7f0d490943c0] co located POCs unavailable
[14:21:26 CEST] <JEEB> but I still recall some things about these things so I'll see if someone responds
[14:21:29 CEST] <JEEB> oh
[14:21:30 CEST] <JEEB> that is H.264 :D
[14:21:30 CEST] <howaboutsynergy> [00007f0d49052f70] avcodec decoder error: more than 81 frames of late video -> dropping frame (computer too slow ?)
[14:21:50 CEST] <howaboutsynergy> oh yeah it's another vid,     Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1280x720 [SAR 1:1 DAR 16:9], 1116 kb/s, 30 fps, 30 tbr, 90k tbn, 60 tbc (default)
[14:22:01 CEST] <JEEB> H.264 should be cut'able on RAPs
[14:22:02 CEST] <howaboutsynergy> Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 125 kb/s (default)
[14:22:27 CEST] <howaboutsynergy> and I used -accurate_seek -acodec copy -aq 1 -vcodec copy
[14:22:36 CEST] <JEEB> umm
[14:22:43 CEST] <howaboutsynergy> the "-aq 1" is useless there right? I dno why I had it
[14:22:45 CEST] <JEEB> not sure -aq 1 or -accurate_seek do anything
[14:22:55 CEST] <JEEB> or latter might do something, and I wonder if it does anything good
[14:23:21 CEST] <howaboutsynergy> yeah, accurrate seek is default anyway, but yeah both must be leftovers for when I didn't use copy at all!
[14:23:56 CEST] <howaboutsynergy> "seeking is accurate when transcoding"
[14:24:08 CEST] <JEEB> ok, seems like the value is only utilized in ffmpeg_filter.c
[14:24:10 CEST] <howaboutsynergy> "which may be useful e.g. when copying some streams and transcoding the others."
[14:24:22 CEST] <howaboutsynergy> so, it's useless with copy?
[14:24:26 CEST] <JEEB> yes
[14:24:33 CEST] <JEEB> since you can only be more "accurate" in that sense if you are decoding
[14:24:45 CEST] <JEEB> howaboutsynergy: btw was your input container MPEG-TS in that case?
[14:24:51 CEST] <JEEB> since I see the 90k tbn
[14:25:26 CEST] <howaboutsynergy> -ss " When used as an input option (before "-i"), seeks in this input file to position. Note that in most formats it is not possible to seek exactly, so ffmpeg will seek to the closest seek point before position. When transcoding and -accurate_seek is enabled (the
[14:25:26 CEST] <howaboutsynergy>  default), this extra segment between the seek point and position will be decoded and discarded. When doing stream copy or when -noaccurate_seek is used, it will be preserved."
[14:25:43 CEST] <JEEB> yes
[14:26:44 CEST] <howaboutsynergy> yeah makes sense what you said. I don't know what the input container was when youtube-dl got it, but before cutting it was the same ".mp4"
[14:27:29 CEST] <JEEB> ok
[14:27:44 CEST] <howaboutsynergy> or can I run something on it that tell you more info about the container?
[14:27:50 CEST] <howaboutsynergy> tells*
[14:28:01 CEST] <JEEB> `ffprobe -v verbose -i FILE` gives you a general overlook
[14:28:05 CEST] <JEEB> like the format etc
[14:28:22 CEST] <JEEB> so for mp4 you get mp4, and then the streams etc
[14:29:58 CEST] <JEEB> there are then special tools to look at the details if you need to get those
[14:30:10 CEST] <howaboutsynergy> ffprobe is what I used but without the -v verbose
[14:30:32 CEST] <JEEB> yea, you mostly posted the part that says something about the streams within
[14:30:37 CEST] <howaboutsynergy> ok, so since vlc is the only one garbling, i guess I can rest assured it wasn't ffmpeg
[14:30:50 CEST] <howaboutsynergy> Input #0, mov,mp4,m4a,3gp,3g2,mj2
[14:30:57 CEST] <JEEB> you can test decoding with something like `ffmpeg -v verbose -i FILE -f null -`
[14:31:02 CEST] <howaboutsynergy> compatible_brands: isomiso2avc1mp41
[14:31:09 CEST] <JEEB> yea, so it's mp4-like
[14:31:13 CEST] <JEEB> probably mp4
[14:31:28 CEST] <JEEB> which should have a global index (Generally) and proper fields for RAPs
[14:31:49 CEST] <howaboutsynergy> the extension is .mp4
[14:32:06 CEST] <howaboutsynergy> encoder         : Lavf58.26.101
[14:32:11 CEST] <howaboutsynergy> cool
[14:32:27 CEST] <JEEB> then for various formats there's actual inspectors
[14:32:39 CEST] <howaboutsynergy> I tried VLC media player 4.0.0-dev Otto Chriek (revision 4.0.0-dev-7321-gdb9131787a)
[14:32:39 CEST] <JEEB> but in this case I don't think you need those :)
[14:32:42 CEST] <kubast2_> Does tune makes any difference when doing lossless x264 like use -crf 0/ -qp 0 -qpmin 0 -qpmax 0  ?
[14:33:00 CEST] <kubast2_> As in
[14:33:05 CEST] <JEEB> kubast2_: I don't think you need to set min/max :P
[14:33:09 CEST] <kubast2_> Is it possible for the output material to be different
[14:33:09 CEST] <JEEB> with libx264 at least
[14:33:18 CEST] <JEEB> you just set -q:v or whatever to zero
[14:33:25 CEST] <JEEB> (crf zero works for 8bit)
[14:33:48 CEST] <JEEB> kubast2_: I don't think anything set in tunes generally affects lossless mode too much
[14:35:47 CEST] <kubast2_> I guess I can always convert the files to rawvideo and check if there's a difference
[14:35:59 CEST] <JEEB> there shouldn't be :)
[14:36:10 CEST] <JEEB> lossless if enabled is always lossless
[14:36:38 CEST] <JEEB> at most tune fastdecode or zerolatency affect compression efficiency
[14:42:29 CEST] <JEEB> howaboutsynergy: VP9 seems apparently to reset coder state on RAPs so as long as they're correctly marked it should JustWork
[14:43:57 CEST] <howaboutsynergy> what's a RAP? relative access point?
[14:44:09 CEST] <JEEB> random access point
[14:44:22 CEST] <JEEB> because a "keyframe" talks only about a single frame
[14:44:23 CEST] <howaboutsynergy> oh right, (pretending to know what that's about xD)
[14:44:34 CEST] <JEEB> it does not make a promise about being able to decode what comes after
[14:44:58 CEST] <JEEB> while RAP always means that what comes after in presentation order should be decode'able as well
[14:47:24 CEST] <dongs> JEEB: dongs
[14:48:05 CEST] <JEEB> exactly
[14:48:28 CEST] <JEEB> thanks for the sample, although I couldn't parse it as LATM I think
[14:49:34 CEST] <dongs> i handle 22ch shit same way as < 22ch, which is just prepend length header or wahtever
[14:49:37 CEST] <dongs> and dump
[14:49:40 CEST] <dongs> i donno if thats wrong or not
[14:50:31 CEST] <JEEB> yea, as bit stream it should be the same so no special handling there methinks
[14:50:39 CEST] <dongs> 		hdr[0] = 0x56; 		hdr[1] = 0xE0 | ((pInfo->Length >> 8) & 0xF); 		hdr[2] = pInfo->Length & 0xFF;
[14:52:25 CEST] <furq> kubast2_: use the hash muxer if you want to compare two decoded files
[14:52:50 CEST] <furq> ffmpeg -v error -i foo.mp4 -i bar.mp4 -map 0 -f hash - -map 1 -f hash -
[14:53:07 CEST] <dongs> JEEB: unless it was split across separate PIDs and i didnt notice
[14:53:14 CEST] <dongs> anyway, the dump there is raw dump + latm header.
[14:53:21 CEST] <dongs> whats beyond it is either trash or ?? i donno.
[14:53:27 CEST] <dongs> since not 100% sure of crypto either.
[14:53:33 CEST] <JEEB> aye
[14:53:40 CEST] <dongs> unfortunately 8K is crypto even during sleep time
[14:53:45 CEST] <dongs> unlike 4K
[14:53:47 CEST] <dongs> whcih is in teh clear
[14:53:59 CEST] <dongs> so i don't have a baseline
[14:54:27 CEST] <JEEB> yea I just noticed it mentioned something about multiple programs so the insane people might have decided to do sub-streams in LATM
[14:54:36 CEST] <dongs> im back in japan so i'll be poking with this again as soon asi get my desk from exploded state
[14:59:14 CEST] <JEEB> I'll probably poke a bit more on the MMTP part after I get over some other stuff I'd like to move forwards
[14:59:23 CEST] <JEEB> since I think I've got TLV more or less OK
[15:00:10 CEST] <howaboutsynergy> looks like -nostdin is pretty much what I always want to specify on every ffmpeg command
[15:02:46 CEST] <kubast2_> furq they all have different hashes
[15:03:15 CEST] <kubast2_> I did both converssion to rawvideo with the same pix format and using the hash mux
[15:03:34 CEST] <kubast2_> tune modifies lossless video then?
[15:03:40 CEST] <furq> by decoded i meant the decoded contents
[15:03:45 CEST] <furq> you can use it on the encoded files
[15:04:07 CEST] <kubast2_> Yeah I used the muxer on encoded frame/file
[15:04:14 CEST] <kubast2_> Well gonna check one more thing tbh
[15:04:22 CEST] <furq> are you enabling the vbv
[15:04:32 CEST] <furq> x264 output is nondeterministic if you use multithreading and enable vbv
[15:04:32 CEST] <kubast2_> vbv?
[15:04:36 CEST] <furq> maxrate/bufsize
[15:04:43 CEST] <furq> probably not if it's lossless
[15:04:55 CEST] <kubast2_> I used none options for maxrate and bufsize
[15:05:04 CEST] <kubast2_> And if ffmpeg uses multithreading by default
[15:05:16 CEST] <kubast2_> Then yes I did use it and didn't add -threads 1
[15:05:17 CEST] <furq> well libx264 does by default
[15:05:26 CEST] <furq> but one or the other is fine
[15:05:29 CEST] <furq> it's just if both are enabled
[15:06:27 CEST] <furq> also i guess you want -map 0:v and -map 1:v if the files have audio
[15:06:50 CEST] <kubast2_> Ah I'm an idiot
[15:10:04 CEST] <kubast2_> The hashes are still different, but yeah I forgot to use -crf 0 :^)
[15:10:46 CEST] <kubast2_> And now I put -crf 0 in a wrong place :^) I will just open bash history file and fix it there
[15:10:58 CEST] <kubast2_> And redo it as one command
[15:15:44 CEST] <kubast2_> Yep
[15:15:46 CEST] <kubast2_> Same hash
[15:29:58 CEST] <howaboutsynergy> What do they mean here by timestamps being copied? " Note that if you specify -ss before -i only, the timestamps will be reset to zero, so -t and -to have not the same effect. If you want to keep the original timestamps, add the -copytsoption. " from https://trac.ffmpeg.org/wiki/Seeking#Cuttingsmallsections
[15:30:56 CEST] <howaboutsynergy> and is that 'not' a type for 'now' ? in "so -t and -to have not the same effect"
[15:31:10 CEST] <howaboutsynergy> typo*
[15:33:22 CEST] <howaboutsynergy> oh i understand it now that I read the 3 explained examples  which follow
[15:39:03 CEST] <howaboutsynergy> I recompiled vlc, same garblage at the beginning and boy vlc changed, now I've 2 windows: one for video and one for playlist+menu.
[16:19:51 CEST] <Atlenohen> JEEB,Cehoyos,furq: I had to go and document things from the get go to figure this out, infact this picture is the draft of what will be a new guide, I should have analyzed the build log earlier it turned out to be very helpful
[16:20:15 CEST] <Atlenohen> https://i.imgur.com/U89cCmO.png
[16:21:27 CEST] <Atlenohen> The configure file would need some updates, but this is just bare to get it working, there's a lot of stuff that's "unknown option" which I can summarize later, will probably put it all on a bug ticket
[16:23:00 CEST] <Atlenohen> As for BCrypt, after I finished the graphic, I went and tried if it's the version issue, with Win10 SDK, I basically made a copy of the LIBs and INCLUDEs of Win10SDK's older version and make them to be fakes, renamed to a folder of the new version, so it took the old files, but it didn't help
[16:24:19 CEST] <Atlenohen> Finally, it only struck me then at the end of that, well, why the hell don't I try forcing the bcrypt.lib and bcyrpt.h into the final program, who cares if ffmpeg doesn't compile it, I'll just put it there, that worked and sovled the whole issue.
[18:15:00 CEST] <HickHoward> uhhh
[18:15:00 CEST] <HickHoward> so
[18:15:43 CEST] <HickHoward> has anyone ever ripped a netflix video with ffmpeg before?
[18:16:52 CEST] <durandal_1707> that is illegal
[18:17:15 CEST] <HickHoward> oof
[18:29:03 CEST] <aboxer> I am converting h264 to h265 with this command:  ffmpeg -i IN.ts  -c:v libx265 -preset ultrafast -x265-params lossless=0 OUTPUT.ts
[18:29:22 CEST] <aboxer> I would also like to convert ATSC closed captions
[18:29:28 CEST] <aboxer> what am I missing ?
[18:30:14 CEST] <JEEB> quickly looked at the libx265.c wrapper here
[18:30:19 CEST] <JEEB> and I don't see it touching the side data
[18:31:11 CEST] <aboxer> o o
[18:31:16 CEST] <aboxer> thanks, JEEB
[18:31:16 CEST] <JEEB> I mean, touching the side data that contains the captions
[18:31:20 CEST] <aboxer> yes
[18:31:55 CEST] <aboxer> plan B is to find an h265 sample with SEI closed captions
[18:36:16 CEST] <aboxer> JEEB: is there an issue open for CC conversion for h265 ?
[18:39:53 CEST] <aboxer> I found a sample file, btw:  https://streams.videolan.org/streams/ts/CC/hevc_cc.ts
[18:54:48 CEST] <lrusak> I'm only getting about 90fps when transcoding with vaapi, is that normal?
[18:55:03 CEST] <lrusak> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i input.mkv -c:v hevc_vaapi output.mkv
[18:55:17 CEST] <JEEB> could be normal, depends heavily on what the hardware can provide
[18:55:35 CEST] <JEEB> it's more than real time for a lot of stuff so I would expect that to be what's expected
[18:55:51 CEST] <JEEB> (because 60Hz is usually most you get with broadcast/streaming)
[18:58:14 CEST] <lrusak> Ok, it's a kaby lake i7, and the content is 23.976
[19:15:29 CEST] <jkqxz> lrusak:  The default compression level in some drivers trades a lot of speed for a marginal quality gain in the encode.  Try "-compression_level 100" (some large number, it'll tell you what he upper bound is).
[19:25:02 CEST] <lrusak> [hevc_vaapi @ 0x564f25964200] Invalid compression level: valid range is 0-7, using 7.
[19:25:25 CEST] <lrusak> I don't seem much difference though when using different vaues
[20:11:19 CEST] <ncouloute> When I use the concat demuxer to combine several cfr mp4s I'm getting a variable framerate file back. Is there any way to get it to output cfr without reencoding?
[20:16:14 CEST] <Ariyasu> is the frame rate the same in each file?
[20:16:40 CEST] <Ariyasu> if you concat somthing thats 25fps and somthing thats 50fps, while both have cfr the output will be vfr
[20:17:24 CEST] <Ariyasu> and if it's the case that your source files have differing framerates, you would have to encode to get them all to match and you probably dont want to be doing that
[20:17:38 CEST] <Ariyasu> changing framerate is noramlly a bad idea
[20:30:46 CEST] <ncouloute> yes each file has the same constant framerate of 60000/1001 In fact I encode them with ffmpeg at first.. then concat after
[20:31:45 CEST] <JEEB> ncouloute: you should check the timestamp diffs with either ffprobe or l-smash's boxdumper
[21:07:09 CEST] <ncouloute> How would I go about that. Starting at second frame the pkt_pts and pkt_dts is off. Too much info going on with ffprobe. Going to give boxdumper a shot less output
[21:07:13 CEST] <ncouloute> I tried using the concat protocol and that seems to generate a file that is only slightly variable. Although that is 3 ffmpeg statments. one to mux each file to ts and then stitch the files together then remux to mp4. Another approach would be to concat during the initial encode might work be better that way.
[21:46:15 CEST] <Atlenohen> Is there some kind of an explanation to the configure file
[21:46:28 CEST] <Atlenohen> it's like totally undocumented of what's what
[21:48:15 CEST] <Atlenohen> these tests that are being done ff.conf_9djdsnj87c.test  are they even needed for building?
[21:49:09 CEST] <Atlenohen> so many repeating tests in the config.log, testing what?
[21:49:52 CEST] <Atlenohen> I know it generates the things and checks for valid paths but, how roughly how much is strictly necessary ?
[22:34:09 CEST] <Atlenohen> install command also copies shared text files
[22:34:26 CEST] <Atlenohen> but in makefile it only speifies libs and headers
[23:26:54 CEST] <Atlenohen> I have received word from other people that static libs aren't going to pack other libs like bcrypt.lib anyway so it's not ffmpeg fault
[23:27:33 CEST] <Atlenohen> Not sure if it's that true, however, ffmpeg's build log could be designed to output a list of dependencies that may be needed later on
[00:00:00 CEST] --- Mon Apr 15 2019