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

[burek]

[00:21:49 CEST] <Chloe> How do I get the ++++---- thing that people always do in their [PATCH 0/n] emails?
[00:22:11 CEST] <Chloe> I dont know what it's called :s
[00:22:38 CEST] <JEEB> [--[no-]cover-letter
[00:23:09 CEST] <JEEB> git format-patch --cover-letter HEAD~2 -o patches
[00:23:20 CEST] <JEEB> or wait, range before the -o
[00:23:45 CEST] <JEEB> and then you can git send-email the directory with patches
[00:23:54 CEST] <JEEB> (together with the cover letter)
[00:24:18 CEST] <Chloe> thanks
[00:49:25 CEST] <jamrial> Chloe: any reason you didn't make sdl2 the default version?
[00:50:05 CEST] <jamrial> if ffplay sdl1 is going to be considered deprecated, it shouldn't be the default version
[00:50:45 CEST] <JEEB> agreed
[01:31:51 CEST] <rcombs> Chloe: you can also see it by doing `git diff --stat`
[01:31:55 CEST] <rcombs> or show --stat
[02:37:58 CEST] <cone-054> ffmpeg 03Michael Niedermayer 07master:6f062eb8d0e1: avformat/hlsenc: Emulate strftime("%z") using other functions if it does not work
[12:23:29 CEST] <cone-297> ffmpeg 03Nikolas Bowe 07master:96cd6f672e5d: avcodec/(e)ac3: Fix target_level for EAC3.
[13:41:34 CEST] <JEEB> welp, was testing offsetting the DTS/PTS and -itsoffset with ismv doesn't seem to get into the tfxd boxes :<
[13:41:47 CEST] <JEEB> > fragment_dts = 0, fragment_duration = as expected
[13:53:24 CEST] <cone-297> ffmpeg 03Martin Storsjö 07master:f8a13c72132a: lavf/rtsp: Fix a crash with the RTSP muxer.
[14:07:26 CEST] Action: JEEB goes look at how itsoffset works
[14:34:07 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vioqb
[14:34:07 CEST] <KGB> 13FFV1/06master 14d21aafc 15Jérôme Martinez: Median Predictor formula update...
[14:40:36 CEST] <JEEB> ooh, I see
[14:40:53 CEST] <JEEB> movenc.c checks if timestamps are bigger than integer
[14:41:03 CEST] <BBB> holy crap kodas quoting ...
[14:41:15 CEST] <JEEB> [ismv @ 0x30c39e0] Application provided initial timestamp: 2999573333 is out of range for mov/mp4 format
[14:41:26 CEST] <JEEB> -itsoffset 300 seconds
[14:41:35 CEST] <JEEB> in ismv's timebase
[14:43:27 CEST] <JEEB> so it resets the initial timestamp et al to zero
[15:26:09 CEST] <JEEB> oh "yay", avconv seems to do what I want timestamp wise :/ time to find out WTF is fucking with my segment timestamps and where in FFmpeg's libavformat
[15:53:05 CEST] <cone-297> ffmpeg 03Moritz Barsnick 07master:022260271b17: libavcodec/qsvdec_h2645.c: drop executable permission
[16:27:19 CEST] <Chloe> I got no explicit approvals for my sdl2 set, does this just mean that I decide when to push?
[16:28:16 CEST] <Chloe> or rather, what should I do?
[16:38:18 CEST] <ubitux> source.ffmpeg.org down?
[16:38:27 CEST] <ubitux> it changed to git.ffmpeg.org?
[16:39:23 CEST] <jamrial> ubitux: i can pull from source.ffmpeg.org just fine
[16:40:02 CEST] <jamrial> trying that on a browser redirects me to git.videolan.org, though
[16:40:20 CEST] <ubitux> - ping source.ffmpeg.org
[16:40:23 CEST] <ubitux> ping: source.ffmpeg.org: Name or service not known
[16:40:34 CEST] <ubitux> ffmpeg.org/downloads also documents as git.ffmpeg.org
[16:41:21 CEST] <Chloe> ubitux: works for me 'source.ffmpeg.org is an alias for git.videolan.org. git.videolan.org is an alias for albiero.videolan.org.'
[16:41:31 CEST] <ubitux> curious
[16:41:39 CEST] <bencoh> source.ffmpeg.org.      600     IN      CNAME   git.videolan.org.
[16:41:39 CEST] <bencoh> ;; Received 62 bytes from 79.124.17.100#53(79.124.17.100) in 34 ms
[16:41:49 CEST] <bencoh> something wrong with your resolver maybe?
[16:42:03 CEST] <ubitux> yeah probably, i'm going to check this
[16:43:46 CEST] <bencoh> is source.ffmpeg.org just legacy from the time videolan hosted official git btw?
[16:43:54 CEST] <JEEB> doesn't it still?
[16:44:26 CEST] <bencoh> dunno ... what is git.ffmpeg.org for then? just having an official mirror around?
[16:46:10 CEST] <RiCON> just a cname to git.videolan.org
[16:46:42 CEST] <Chloe> JEEB: yeah, it still does
[16:46:44 CEST] <RiCON> oh, git.
[16:49:41 CEST] <ubitux> i guess i shouldn't rely on systemd-resolved
[17:01:29 CEST] <cone-297> ffmpeg 03Paul B Mahol 07master:4d677c7ae37d: avformat/msf: add support for ATRAC3 codec
[17:02:05 CEST] <Chloe> jamrial; I'm pretty sure it wouldnt fail between the copy patch and the sdl2 ffplay patch
[17:02:43 CEST] <Chloe> I tried to make it so it wouldnt, and if it does fail then I'll fix it. I'd much rather have them as separate patches than one massive patch
[17:03:00 CEST] Action: JEEB is finding out how itsoffset (ts_offset) is actually pushed through libavformat
[17:03:21 CEST] <Chloe> I did test it though, and it worked, although it may be broken for carl or you?
[17:05:54 CEST] <jamrial> Chloe: you're right, missed the fact configure still makes ffplay depend on sdl1 at that point
[17:06:04 CEST] <Chloe> yes that's fine
[17:06:26 CEST] <jamrial> the patches are fine as is then
[17:07:25 CEST] <Chloe> what will happen is: HAVE_SDL2 will be false, so ffplay.c will be commented out, HAVE_SDL will be true so ffplay_sdl1.c will be added to the ffplay target. Since ffplay.c and ffplay_sdl1.c are the same it keeps the same behaviour
[17:15:37 CEST] <nevcairiel> one thing i wondered about that, cant you just add one of those two files, depending on HAVE_SDL2 or HAVE_SDL
[17:15:45 CEST] <nevcairiel> instead of having an ifdef
[17:19:27 CEST] <Chloe> that's originally what I thought but jamrial said you'd have to quite dig deep into the build system to have ffplay not include ffplay.c
[17:20:12 CEST] <nevcairiel> that sounds odd
[17:20:22 CEST] <nevcairiel> why can you optionally compile one file but not another
[17:21:18 CEST] <JEEB> [ismv @ 0x3525c00] pkt dts=0, pts=0, duration=333667 , [ismv @ 0x27eb3c0] pkt dts=2999513333, pts=2999513333, duration=213333 <- ok, so libav pushes the offset to dts/pts
[17:21:27 CEST] <JEEB> but FFmpeg doesn't for whatever reason
[17:21:31 CEST] Action: JEEB scratches head
[17:29:38 CEST] <Chloe> nevcairiel: ffplay.c is standard
[17:30:04 CEST] <cone-297> ffmpeg 03Paul B Mahol 07master:b82c1a377a2b: avcodec/adpcm: clip step for ADPCM MTAF decoder
[17:41:54 CEST] <jamrial> nevcairiel: look at define DOPROG in Makefile, ffplay.o is included unconditionally
[17:57:10 CEST] <ubitux> are we really going to have 2 ffplay in the repository?
[17:58:08 CEST] <jamrial> no, just two separate source files instead of one full of ifdeffery
[17:58:27 CEST] <jamrial> if you prefer the latter then comment in the thread. nobody is objecting, so...
[18:00:08 CEST] <ubitux> not really fan of this but well
[18:01:00 CEST] <ubitux> is ffplay converted to codecpar yet?
[18:01:06 CEST] <jamrial> yeah
[18:01:44 CEST] <ubitux> two ffplay to maintain and only one testable at once is going to be really annoying
[18:02:14 CEST] <ubitux> i'd just drop sdl1 support in ffplay tbh
[18:02:22 CEST] <jamrial> ubitux: Chloe is going to maintain the sdl1 version until next year
[18:02:41 CEST] <jamrial> and be considered deprecated until then. actual development will happen in the sdl2 version
[18:02:53 CEST] <ubitux> ok...
[18:03:01 CEST] <Chloe> yep, only fixes will be backported
[18:03:07 CEST] <jamrial> ubitux: and that was the original idea, but at least Carl and michaelni use old distros without sdl2
[18:09:05 CEST] <ubitux> as a desktop?
[18:10:01 CEST] <Chloe> Apparently
[18:10:07 CEST] <jamrial> yeah, Ubuntu 12.04 lts and Debian old-stable
[18:25:25 CEST] <wm4> enjoy having pain to appease this bullshit
[18:28:21 CEST] <durandal_1707> pain to communicate with Carl?
[18:29:06 CEST] <wm4> maintaining two ffplays
[18:29:15 CEST] <Chloe> rip me
[18:30:16 CEST] <philipl> ffplay is too much awesom to fit into one file...
[18:30:57 CEST] <durandal_1707> ffmbc removed ffplay, we should too
[18:32:21 CEST] <jamrial> then go ahead and turn ffplay.c into an ifdeffery mess and make Marton's life miserable, if having two separate source files is so annoying to see
[18:33:33 CEST] <Chloe> I strongly object to that
[18:35:50 CEST] <jamrial> philipl: well, ffmpeg apparently needs to live in like eight, so...
[18:37:06 CEST] <wm4> jamrial: I should have said, supporting 2 SDLs
[18:39:49 CEST] <durandal_1707> and two SDL devices?
[18:42:22 CEST] <jamrial> not too different than supporting four different tls libraries for the tls module that can't coexist with each other
[18:44:38 CEST] <jamrial> personally i'd just go and drop sdl1 support since i don't care about it and can use sdl2 just fine, but others apparently can't and we have someone willing to keep sdl1 working until old distros are EOLed early next year
[18:45:16 CEST] <jamrial> so why does it annoy people so much if you're not even getting the burden of maintenance?
[18:48:33 CEST] <wm4> except TLS is actually important
[18:51:05 CEST] <jamrial> i know
[18:59:03 CEST] <jamrial> so, do you all want me to start a vote in the ml about it? I'm fairly certain the drop sdl1 option would win, seeing how it's 4 vs 2 so far
[19:01:29 CEST] <Chloe> jamrial: that sounds like a good idea
[19:10:13 CEST] <ubitux> supporting sdl1 and sdl2 is fine while migrating everything to sdl2
[19:10:20 CEST] <ubitux> but keeping our code compatible with both is insane
[19:11:13 CEST] <jamrial> ubitux: well, both the outdev and ffplay have been migrated, so sdl1 can be dropped just fine right away
[19:11:19 CEST] <JEEB> esp. since people have gotten used to f.ex. 12.04 not having SDL2 (you have PPAs and guides to build it available on the internets)
[19:11:26 CEST] <jamrial> ubitux: i'll start a vote then
[19:11:31 CEST] <ubitux> as developers we are asking our users to use ffmpeg git/head, but we can't manage to have a system up-to-date ourselves?
[19:11:39 CEST] <JEEB> also as I noted, yasm 1.1 in 12.04 f.ex.
[19:11:43 CEST] <JEEB> which won't build current x264 :P
[19:12:08 CEST] <ubitux> old stable user should just use old stable ffmpeg
[19:12:15 CEST] <JEEB> yes
[19:12:24 CEST] <JEEB> I'm just expecting a "you just don't understand" kind of responses
[19:12:37 CEST] <JEEB> like cehoyos's "you are going to make testing impossible for me!"
[19:12:39 CEST] <ubitux> also, it's not the ffmpeg tool here, it's ffplay
[19:12:49 CEST] <ubitux> so ENOCARE
[19:12:52 CEST] <JEEB> yup
[19:12:56 CEST] <JEEB> that's why I didn't herp a derp on the ML
[19:13:00 CEST] <ubitux> there are probably more ffserver users than ffplay
[19:13:07 CEST] <JEEB> because I don't feel that heavily regarding ffplay
[19:13:13 CEST] <JEEB> I have only built it accidentally :/
[19:13:35 CEST] <Chloe> ffplay is more like example code than anything else
[19:13:47 CEST] <ubitux> it's actually a great tool for testing purpose (or even occasionnal playbacks)
[19:13:58 CEST] <JEEB> I agree
[19:14:13 CEST] <JEEB> for random quick testing I've once used it
[19:14:27 CEST] <ubitux> but expecting old-stable users to use keep using a ffmpeg bleeding edge is absurd, unless you are a ffmpeg developer, and this represent 5 to 10 ppl in the world
[19:14:31 CEST] <ubitux> and they should just fucking upgrade
[19:14:43 CEST] <JEEB> or handle a dependency in their own prefix
[19:14:45 CEST] <JEEB> or something
[19:16:11 CEST] <JEEB> anyways, rebooting my dev VM to see if I can get a grasp where the hell ffmpeg.c decides to ignore -itsoffset :/
[19:16:50 CEST] <JEEB> (movenc.c is getting zero'ified timestamps)
[19:36:53 CEST] <jamrial> there
[19:37:32 CEST] <jamrial> let democracy take the blame for the fate of sdl1
[19:42:50 CEST] <Chloe> TIL there's a voting commitee
[19:45:42 CEST] <BBB> we dont use it very often ;)
[19:46:10 CEST] <wm4> <Chloe> ffplay is more like example code than anything else <- nope
[19:46:23 CEST] <durandal_1707> we use it mainly to ban devs
[19:46:37 CEST] <Chloe> when has that ever happened?
[19:46:49 CEST] <jamrial> it hasn't yet
[19:47:08 CEST] <Chloe> wm4: ok
[19:47:47 CEST] <wm4> Chloe: ffplay is a bit too "dense" to be a useful example, and also it's full of rather specific hacks (that prove that the libs don't provide everything)
[19:48:06 CEST] <wm4> you may as well call ffmpeg.c example code
[19:48:32 CEST] <RiCON> ffplay is used when people come with bugs from using mpv that are caused by libav* but cehoyos doesn't accept the bug because mpv isn't ffmpeg
[19:48:34 CEST] <wm4> anyway, ffplay is a perfect candidate to be moved into a separate repo
[19:48:40 CEST] <jamrial> wm4: Marton was able to port it to codepar without trouble, so it's not really that hacky
[19:48:47 CEST] <wm4> that would also force certain ffmpeg devs to deal with API and behavior changes correctly
[19:49:00 CEST] <jamrial> and it doesn't need internal stuff like ffserver
[19:49:22 CEST] <JEEB> yeah, in that evil scale it's: ffserver >= ffmpeg >= ffplay
[19:49:27 CEST] <wm4> AFAIK it used some internal stuff, but that was stripped from it the last few years
[19:49:28 CEST] <jamrial> out of all the examples, it's probably the cleaniest
[19:49:37 CEST] <Chloe> wm4: why not just split all the tools off into a separate repo then?
[19:49:39 CEST] <wm4> so why do we have examples then?
[19:49:44 CEST] <wm4> Chloe: would be a great idea
[19:49:53 CEST] <Chloe> wm4: we dont really have examples though
[19:49:55 CEST] <JEEB> Chloe: that has been mentioned a few times :)
[19:50:03 CEST] <wm4> Chloe: doc/examples/
[19:50:16 CEST] <Chloe> none of them use codecpar
[19:50:35 CEST] <jamrial> one does now
[19:50:50 CEST] <jamrial> another once i commit my porting patch
[19:50:56 CEST] <Chloe> cool
[19:51:23 CEST] <ubitux> btw, ffmpeg*c port is in progress (available in github/ubitux/ffmpeg/codecpar)
[19:51:35 CEST] <ubitux> doesn't pass fate yet (quite a bunch of mismatch)
[19:51:37 CEST] <jamrial> ubitux: awesome
[19:51:42 CEST] <Chloe> What are the arguments against separating tools and library by repo?
[19:51:57 CEST] <wm4> I think my patches for making ffmpeg.c use the new decode API are still pending
[19:52:22 CEST] <wm4> and they fail on... ffmpeg.c doing stupid stuff
[19:52:36 CEST] <wm4> suggestions how to workaround are welcome
[19:52:42 CEST] <durandal_1707> like?
[19:53:25 CEST] <wm4> it sets timestamps (well, DTS) on flush packets
[19:53:29 CEST] <wm4> and expects them back
[19:54:08 CEST] <wm4> flush packets can't have timestamps conceptually, that's just nonsense (because you already sent the timestamps with the proper packets)
[20:05:21 CEST] <jamrial> ubitux: you're not replacing all the bitstream code from the more recent noop'd libav commits here. i think at least one of the FIXME would be gone with that
[20:05:38 CEST] <ubitux> yeah for now i only ported the first commit
[20:05:47 CEST] <ubitux> and that was done very quickly actually
[20:05:54 CEST] <ubitux> i didn't use your squashed diff yet
[20:05:58 CEST] <jamrial> ah ok
[20:06:09 CEST] <ubitux> maybe i should update it with it
[20:06:26 CEST] <ubitux> you think all commits are needed to make it pass fate?
[20:07:11 CEST] <ubitux> because i'd better do it incrementally unless required
[20:13:14 CEST] <jamrial> ubitux: it shouldn't be needed, i think. at least it wasn't for libav
[20:13:24 CEST] <jamrial> but since our codebase is so different, i can't say
[20:13:34 CEST] <ubitux> ok
[21:02:09 CEST] <JEEB> ok... what was the way to create a filter-based input? I'd need 300 pictures at 30/1.001Hz
[21:03:26 CEST] <JEEB> because right now it seems like a video encoder drops the dts/pts to zero or something before it goes to muxer
[21:04:14 CEST] <durandal117> JEEB: ffmpeg -f lavfi -i  testsrc2=duration=10:rate=30/1.001
[21:04:20 CEST] <JEEB> thanks
[21:08:27 CEST] <JEEB> durandal117: cheers, this pretty much settles it I guess
[21:08:39 CEST] <jamrial> ubitux: at least with fate-lavf-mxf_opatom, the problem seems to be that it's ignoring the -vb bitrate option from the command line
[21:08:45 CEST] <JEEB> libx264 at least seems to drop pkt_dts and pkt_pts to zero
[21:08:49 CEST] <jamrial> i bet a lot other tests are failing for the same reason
[21:09:31 CEST] <ubitux> jamrial: oh. okay, thanks :)
[21:09:35 CEST] <jamrial> ubitux: if i instead used -b:v it works
[21:09:42 CEST] <ubitux> strange, ok
[21:09:46 CEST] <ubitux> thanks a lot
[21:09:55 CEST] <jamrial> no prob
[21:09:57 CEST] <ubitux> i was looking at the matroska one before moving on
[21:10:14 CEST] <ubitux> there is one byte off in the header, so probably an information drop somewhere
[21:10:47 CEST] <JEEB> ok, same with mpeg4
[21:16:19 CEST] <JEEB> or well, not same - ffmpeg decides it's a good idea to duplicate over 9000 pictures when only 300 were supposed to be encoded
[21:20:02 CEST] <JEEB> durandal117: http://up-cat.net/p/56fcb551
[21:20:05 CEST] <JEEB> enjoy the funkiness :D
[21:20:29 CEST] <JEEB> filter -> pts:8991 pts_time:300 exact:8991.000008 time_base:1001/30000
[21:20:29 CEST] <JEEB> *** 8991 dup!
[21:20:30 CEST] <JEEB> encoder <- type:video frame_pts:0 frame_pts_time:0 time_base:1001/30000
[21:23:25 CEST] <JEEB> and then if you build l-smash with these patches and do `./cli/boxdumper --box test_output.ismv | less` you will find out that the first tfxd has a zero timestamp indeed vOv
[21:24:47 CEST] <durandal117> JEEB: what it should do instead?
[21:26:08 CEST] <JEEB> first picture should have a timestamp of +300 seconds ? (in tfxd terms that would be 300 * 10000000 )
[21:28:54 CEST] <JEEB> at least that's how I understand -itsoffset
[21:31:27 CEST] <JEEB> seems like avconv does it
[21:31:41 CEST] <durandal117> Assertion next_dts <= 2147483647 failed at libavformat/movenc.c:878
[21:31:42 CEST] <JEEB> but using that is... its own headache and I'd rather not
[21:32:19 CEST] <JEEB> durandal117: funky
[21:32:25 CEST] <JEEB> with the same command?
[21:32:54 CEST] <durandal117> using avi as input
[21:33:09 CEST] <JEEB> I've also used mpeg-ts and matroska as input
[21:33:12 CEST] <JEEB> those seemed to work
[21:33:19 CEST] <JEEB> as in, bring the same result
[21:33:45 CEST] <jamrial> ubitux: http://pastebin.com/wdbaVpEF
[21:34:01 CEST] <jamrial> that's mkvinfo output for the file generated by fate-lavf-mkv
[21:34:13 CEST] <ubitux> oh, cool, thanks
[21:34:35 CEST] <ubitux> i'll look at all of this tmr, unless you want to patch it ofc
[21:36:45 CEST] <jamrial> ubitux: i'll try
[21:37:16 CEST] <ubitux> i haven't done a clean work in various areas, it's really not much tested yet
[21:37:32 CEST] <ubitux> i think i fixed most of the warnings, but there are still a few usages of st->codec in some places
[21:38:17 CEST] <jamrial> ubitux: in this case maybe the new output is desired. it's now reporting field_order as progressive instead of undefined
[21:39:21 CEST] <ubitux> we need to check if it's streamcopy or transcode
[21:39:49 CEST] <ubitux> in case of transcode, maybe something have/could have changed or idk
[21:40:07 CEST] <durandal117> michaelni: itsoffset seems broken
[21:40:56 CEST] <jamrial> ubitux: transcode
[21:41:15 CEST] <philipl> BtbN: Can you look at my cuvid fixes?
[21:41:35 CEST] <JEEB> durandal117: lol I got the same assertion with a 24/1.001Hz Matroska file
[21:41:42 CEST] <BtbN> philipl, not before the weekend.
[21:42:02 CEST] <BtbN> should be fine, but I don't want to push them untested
[21:44:00 CEST] <BtbN> I'm quite surprised it even does something with non-420 formats. As cuvids only supported output format is NV12
[21:45:18 CEST] <JEEB> durandal117: also if you wonder what I'm trying to test from cli is having the timestamps start from the current unix timestamp. some live media servers just love that >_>
[21:45:45 CEST] <JEEB> there's a hack patch for it by wbs, but since itsoffset exists I thought I'd rather use it
[21:47:16 CEST] <philipl> BtbN: It surprised me too. THe parser detects it, decoder accepts it, and you get garbage frames for your trouble.
[21:47:53 CEST] <BtbN> I wonder if the non-420 case just isn't implemented, and it continues going as if it'S 420?
[21:51:01 CEST] <cone-307> ffmpeg 03Matthieu Bouron 07master:140da8e810b2: lavc: add hevc mediacodec decoder
[21:55:52 CEST] <philipl> BtbN: I don't think so. the garbage doesn't move - I think it just writes nothing to the buffer and you just see whatever was there before.
[21:58:00 CEST] <durandal117> michaelni:  ffmpeg -itsoffset 300 -i ~/Videos/red-leaf-tips.avi -c:v copy -an -avoid_negative_ts 0 -movflags +delay_moov out.ismv
[21:58:47 CEST] <ubitux> avi, streamcopy, timing hack options, what could go wrong :D
[21:59:02 CEST] <ubitux> that would make a great fate test :))
[21:59:18 CEST] <JEEB> uhh, if you think *that* is a hack option
[21:59:23 CEST] <JEEB> look at wbs's -ism_offset
[21:59:37 CEST] <JEEB> which just adds an offset in movenc.c :P
[21:59:49 CEST] <wbs> just for the record, it's a patch that I've written which I do not suggest that should be applied in mainline, ever
[21:59:52 CEST] <durandal117> ubitux: its ffmpeg bug, its sets pts to very small value
[22:00:05 CEST] <durandal117> and than it asserts
[22:00:09 CEST] <JEEB> wbs: yes that is what I've been trying to note
[22:00:28 CEST] <JEEB> itsoffset seems to be borked in ffmpeg.c right now so I'm poking regarding that mainly
[22:01:05 CEST] <JEEB> also funky, I've never tried itsoffset with stream copy
[22:01:08 CEST] <durandal117> JEEB: itsoffset seems fine, movenc not
[22:01:23 CEST] <JEEB> well that also has funky stuff, yes
[22:01:24 CEST] <ubitux> JEEB: i meant that it's trying to alter the timings, which is not always a good idea especially when even the common case isn't always exactly well supported
[22:01:37 CEST] <ubitux> but i like it ;)
[22:01:40 CEST] <JEEB> lol
[22:02:10 CEST] <JEEB> yeah, I've not used it with -c copy and currently it seems like the added INT_MAX checks in movenc.c break muxing in various cases
[22:03:09 CEST] <Chloe> michaelni: arent you trying to build 32bit with 64bit sdl libs?
[22:03:59 CEST] <JEEB> ubitux: and yea I guess things would be simpler if I were just applying the offset through API or something. wanted to test it out through ffmpeg.c and then the tail waggled the dog...
[22:04:07 CEST] <michaelni> Chloe, it seems its doing that but i didnt ask for it to do that
[22:04:34 CEST] <Chloe> wouldnt that be an ld issue?
[22:04:40 CEST] <ubitux> JEEB: don't forget to mix it with -ss in input and output option
[22:04:48 CEST] <Chloe> I'm not sure how exactly multilib works on linux
[22:04:52 CEST] <JEEB> ubitux: LOL
[22:04:53 CEST] <ubitux> (and streamcopy more streams)
[22:05:27 CEST] <durandal117> JEEB: is there in mov way to set initial timestamp?
[22:05:44 CEST] <JEEB> in which sense?
[22:05:48 CEST] <durandal117> which is out of INT32 range?
[22:06:16 CEST] <JEEB> I remember completely valid values getting stopped by that check, so yes
[22:06:33 CEST] <JEEB> the INT_MAX check felt really weird
[22:06:39 CEST] <JEEB> and the commit message only linked a random sample
[22:06:46 CEST] <JEEB> so I wasn't sure WTF was going on there
[22:07:07 CEST] <Chloe> michaelni: I dont see how that could  be configure's fault
[22:07:28 CEST] <nevcairiel> configure should probably test if the libraries are available to be used
[22:08:36 CEST] <JEEB> durandal117: let me know if you learn WTF that check was supposed to fix
[22:08:48 CEST] <JEEB> then we can look into the ISOBMFF spec regarding that
[22:09:09 CEST] <JEEB> but as far as I know you can do either 32bit or 64bit timestamps
[22:09:20 CEST] <JEEB> and the muxer in lavf can switch between them
[22:15:29 CEST] <michaelni> JEEB, get_cluster_duration() is 32bit various fields its stored in are unconditionally 32bit, the structs its stored in are 32bit, if it can all be made to work with arbitrary 64bit values that would be much better than the checks
[22:16:44 CEST] <JEEB> thank you
[22:17:01 CEST] <JEEB> (for the explanation)
[22:20:38 CEST] <JEEB> yea, in my case it was the pkt->dts >= INT_MAX check that made things fail
[22:21:03 CEST] <Dresk|Dev> So really basic, I'm using ffmpeg for dshow capture, and it's SPAMMING log messages that's affecting my performance.  Here's the beginning of the lines it spams when capturing : dshow passing through packet of type video size
[22:21:12 CEST] <durandal117> anyway assert0 should not happen
[22:21:17 CEST] <Dresk|Dev> I've been looking into setting the log level and the log flags but to no avail
[22:21:22 CEST] <JEEB> since I wanted to write 2999997000 and limits.h has 2147483647 for INT_MAX
[22:21:25 CEST] <JEEB> and that is quite valid
[22:21:45 CEST] <JEEB> duration might be a different beast but I'm not sure
[22:21:53 CEST] <JEEB> also the check might be specific to some muxed format
[22:23:46 CEST] <Chloe> Dresk|Dev: #ffmpeg
[22:23:54 CEST] <Dresk|Dev> Chloe: Thanks
[22:24:06 CEST] <Dresk|Dev> Chloe: We're using it as a lib though, not the apps
[22:24:21 CEST] <durandal117> JEEB: frag_start that wbs use is 64bit
[22:24:37 CEST] <JEEB> yes
[22:24:48 CEST] <JEEB> also I'm pretty sure dts can be 64bit in ISOBMFF
[22:25:12 CEST] <JEEB> duration I'm not sure but can check
[22:29:13 CEST] <JEEB> "pts and dts are int64 and uint64 in mov and mp4 respectively. not int"
[22:29:20 CEST] <JEEB> vOv
[22:29:49 CEST] <JEEB> and it seems like duration might be limited to 32bit
[22:30:47 CEST] <JEEB> "Sample duration: A 32-bit integer that specifies the duration of each sample."
[22:34:11 CEST] <JEEB> or well, it's a CTS offset
[22:34:17 CEST] <JEEB> so it's an offset off of DTS
[22:34:40 CEST] <durandal117> then   } else if (pkt->dts <= INT_MIN || pkt->dts >= INT_MAX) {
[22:34:43 CEST] <durandal117> is wrong
[22:34:47 CEST] <JEEB> definitely
[22:35:12 CEST] <durandal117> it should set start pts of track
[22:35:26 CEST] <JEEB> that's the one that I was really sure of. and for PTS it's a 32bit offset off of DTS
[22:35:40 CEST] <JEEB> so if DTS and PTS differ by more than 32bit int then it's invalid
[22:37:14 CEST] <durandal117> and that is checked before wrong check
[22:39:21 CEST] <durandal117> michaelni: what sample 68f4c2163ec6d4534ae1756dbcf259845f2e4d2c fix?
[22:39:45 CEST] <JEEB> b84b53855a0b74560e64c6f45f505a13/signal_sigabrt_7ffff6ae7c37_3837_ef4e243ea5b4fa8d0becf4afe9166604.avi
[22:39:53 CEST] <JEEB> which is probably google internal or whatever?
[22:40:05 CEST] <JEEB> because it's the usual j00ru security stuff
[22:41:19 CEST] <durandal117> JEEB: i asked for actual sample, not its name :D
[22:41:28 CEST] <JEEB> :D
[23:44:20 CEST] <durandal117> michaelni: did you consider adding telecine detection to idet?
[23:47:34 CEST] <rcombs> durandal117: doesn't idet already provide the necessary information to determine telecine? (repeated fields)
[23:51:50 CEST] <durandal117> rcombs: maybe, but it reports 0 for telecined video
[23:51:57 CEST] <rcombs> oh, well then
[00:00:00 CEST] --- Fri Sep 16 2016