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

[burek]

[01:58:23 CEST] <cone-202> ffmpeg 03Steven Liu 07master:84aebfc74ee3: avformat/flvenc: add FLVFlags for flvflags options
[02:25:40 CEST] <llogan> HLS muxer docs are a mess
[05:17:58 CEST] <cone-410> ffmpeg 03Jon Toohill 07master:7f386bbe2a79: ffmpeg: copy trailing_padding when using -acodec copy
[10:03:59 CEST] <cone-355> ffmpeg 03Clément BSsch 07master:ae1dd0c9a616: lavf: add avformat_transfer_internal_stream_timing_info() and use it in ffmpeg
[10:03:59 CEST] <cone-355> ffmpeg 03Clément BSsch 07master:9112822e7109: lavf/utils: simplify matching MOV-like formats
[10:03:59 CEST] <cone-355> ffmpeg 03Clément BSsch 07master:415f907ce8dc: lavf/utils: add missing ismv in MOV-like formats
[13:40:08 CEST] <durandal_17> michaelni: it is triggered for any h264 file with SEI_PIC_STRUCT_TOP_FIELD/BOTTOM_FIELD sei timing
[13:58:06 CEST] <durandal_17> michaelni: is there something missing in h264 parser related to this?
[14:08:34 CEST] <michaelni> durandal_17, i dont know i dont have a testcase to see what exactly happens
[14:10:29 CEST] <durandal_17> michaelni: parser split each packet into two frames, each frame is separate field, every 2n field have no pts
[14:11:23 CEST] <michaelni> pts handling with h264 parser are incomplete
[14:15:31 CEST] <michaelni> IIRC there are 4 variants that the spec requires to be implemented pts computation
[14:21:42 CEST] <durandal_17> michaelni: do you have spec?
[14:22:30 CEST] <michaelni> durandal_17, these 4 variants are described in H.222 (which should be public or at least was)
[14:22:44 CEST] <michaelni> that is all, assuming i guess correctly that this is the issue
[14:28:39 CEST] <durandal_17> michaelni: see this hack: https://gist.github.com/richardpl/cdc2d21268cde6c127364ac0b0836751
[14:47:33 CEST] <michaelni> durandal_17, see: 4eb49fdde8f84d54a763cfb5d355527b525ee2bf maybe reverting that or adding something similar could be part of a fix
[14:53:49 CEST] <durandal_17> michaelni: i know that commit, and i think that is wrong direction, isn't it?
[15:04:36 CEST] <michaelni> I think the commit should be reverted (after carefull testing) if that indeed fixes the issue, does it ?
[15:09:13 CEST] <michaelni> I think this code was just part of what H.222 requires and no heuristic
[15:09:17 CEST] <nevcairiel> the timestamps from that commit were often more wrong then r ight
[15:09:41 CEST] <nevcairiel> and if its h264 specific maybe shouldnt be in generic code
[15:10:33 CEST] <michaelni> it can be moved to h264_something.c but might need to be called from generic code
[15:16:06 CEST] <michaelni> nevcairiel, can you add a fate test for the case(s) where this code was giving wrong results ?
[15:16:21 CEST] <nevcairiel> no
[15:16:29 CEST] <nevcairiel> its been years and i dont remember which samples
[15:16:32 CEST] <michaelni> whoever implements whatever solution would benefit from such test
[15:37:10 CEST] <ubitux> i wonder if our codepar merge really works
[15:39:02 CEST] <durandal_17> michaelni: while that reverted commit fixes timestamps, QuickTime player still incorrectly plays frames, in wrong order
[15:54:53 CEST] <cone-938> ffmpeg 03Michael Niedermayer 07master:e85c4a470651: avformat/flvenc: Add () around &
[15:54:54 CEST] <cone-938> ffmpeg 03Steven Liu 07master:c8528e54e578: avformat/flvenc: add no_sequence_end flags for flvflags
[15:54:55 CEST] <cone-938> ffmpeg 03Xinzheng Zhang 07master:ecc04b4f2f29: avformat/utils: fix timebase error in avformat_seek_file()
[15:54:56 CEST] <cone-938> ffmpeg 03Michael Niedermayer 07master:a5af1240fce8: avcodec/g726: Add missing ADDB output mask
[16:26:37 CEST] <durandal_17> michaelni: actually adopting that commit fixes issue
[16:30:45 CEST] <durandal_17> michaelni: i just need stream timebase
[16:31:28 CEST] <nevcairiel> pkt_timebase is the stream timebase
[16:32:11 CEST] <nevcairiel> from a avcodeccontext, unless i misunderstood what you want
[16:35:18 CEST] <durandal_17> nevcairiel: yes that is it, thanks
[16:53:54 CEST] Action: durandal_17 wonders why codec specific code was located in generic code
[17:53:15 CEST] <cone-938> ffmpeg 03Carl Eugen Hoyos 07master:93e041026f3c: lavc: Enable a53cc by default for x264 and qsv_h264.
[19:54:33 CEST] <durandal117> michaelni: can i use av_rescale?
[19:56:23 CEST] <michaelni> yes
[20:31:34 CEST] <durandal117> michaelni: FYI this is type of h264 encoding that have missing pts when stream coping to mov: http://www.cccp-project.net/beta/test_files/GZ.Sony.HDR-SR1.H264.PAFF.1440x1088.15mbps.m2ts
[21:09:02 CEST] <cone-938> ffmpeg 03Paul B Mahol 07master:01fa4fb69e40: avcodec/h264_parser: set missing pts for top/bottom field frames
[21:15:33 CEST] <cone-938> ffmpeg 03Paul B Mahol 07master:92dbd6570033: avcodec/h264_parser: fix for possible overflow
[21:39:52 CEST] <JEEB> durandal117: wonder why that interlacism timestamp stuff didn't have tests timestamp-wise
[21:48:36 CEST] <durandal117> JEEB: lazy devs
[21:49:04 CEST] <JEEB> aren't we all :)
[21:49:18 CEST] <JEEB> I should finally get to posting the patches I updated to current HEAD @ VDD
[21:55:41 CEST] <Chloe> which are those?
[21:55:55 CEST] <JEEB> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/191735.html
[21:56:17 CEST] <JEEB> because a streaming server wanted ismv >_>
[21:57:19 CEST] <Chloe> Did it just not get merged or..?
[21:57:27 CEST] <JEEB> one of them changed a test's result
[21:57:35 CEST] <JEEB> and I was :effort: to deal with that at the time
[21:57:52 CEST] <JEEB> got the ones that don't change test results rebased and now working with the new internals https://github.com/jeeb/ffmpeg/commits/isml_improvements_rebased
[21:58:36 CEST] <Chloe> nice
[21:58:42 CEST] <JEEB> I'll probably post them on the ML towards the end of the week
[21:59:25 CEST] <JEEB> not sure of this one, but should be OK as the default value is zero for the par->bit_rate https://github.com/jeeb/ffmpeg/commit/298d88f6c24383eb66a05505f7c80cae1f5378cd#diff-ee9f1598eabbf54de15b68d4df0535d3R3623
[21:59:59 CEST] <Chloe> I'm probably going to resubmit the set, as the convo has gone all over the place, as: SDL2 device added, ffplay renamed, ffplay (sdl2) added. but I'm not entirely sure if that'd be the best way to submit it (with a separate rename patch for ffplay)
[22:01:03 CEST] <Chloe> JEEB: two ternary on one line?
[22:01:09 CEST] <JEEB> yeah
[22:01:17 CEST] <JEEB> it was simpler when avctx was available there :)
[22:01:34 CEST] <JEEB> now codecpar has the maxrate in side data prop :)
[22:01:52 CEST] <JEEB> which does make sense of course, it just requires the pointer check there
[22:02:41 CEST] <Chloe> I'd write that as http://sprunge.us/XRBh?c tbh
[22:03:24 CEST] <Chloe> probably get compiled to the same thing, just looks a lot clearer imo.
[22:03:41 CEST] <JEEB> yeah, I'll probably make it like that
[22:04:46 CEST] <Chloe> hmm, maybe I should copy ffplay rather than rename it, and then apply the patch on top, as to keep a linear history
[22:05:03 CEST] <Chloe> michaelni: any suggestions?
[22:13:44 CEST] <jamrial> Chloe: sounds good
[22:14:06 CEST] <JEEB> also with regards 12.04 and SDL2... I would bet people would have to build things by themselves a lot on such a system anyways
[22:14:07 CEST] <jamrial> make sure to create a minimal patch for the ml using the detect copies option in git. ffplay.c is a big file
[22:14:31 CEST] <JEEB> so I wouldn't be against making 12.04 people having to build SDL2 by themselves first (or using a PPA)
[22:16:35 CEST] <JEEB> seems like people build it themselves on such machines https://gist.github.com/Vinatorul/4b3ca4c1b96c18b110db
[22:16:56 CEST] <JEEB> (I would use a custom prefix in that case, but yunno)
[22:20:40 CEST] <nevcairiel> A release of FFmpeg will never reach that version anyway, and people trying to manually update things on such an old system should be well accustomed to getting deps in place
[22:22:05 CEST] <Chloe> hmm, how would I make a copy of it, would I add another program to PROGRAM_LIST? is there an old commit which does something similar maybe?
[22:28:26 CEST] <michaelni> Chloe, copy is better, yes
[22:28:52 CEST] <Chloe> ah, I got it. In the makefile I can change the sources based on HAVE_SDL etc, no need to make another target
[22:28:55 CEST] <Chloe> ok
[22:40:49 CEST] <JEEB> nevcairiel: yeah... for example you can't build x264 on 12.04 either
[22:40:56 CEST] <JEEB> since 12.04 has yasm 1.1.0
[22:41:03 CEST] <JEEB> and the x264 configure script requires 1.2.0
[22:41:12 CEST] <JEEB> (or newer)
[22:41:31 CEST] <nevcairiel> Speaking of we should really bump that and get rid of all them checks everywhere
[22:42:24 CEST] <JEEB> I was going to post on the ML regarding such things, but I'm not sure if I should since I don't feel too strongly about keeping two versions of ffplay...
[22:42:30 CEST] <jamrial> JEEB: x264 never really cared about being compatible with old but maintained distros. they bumped the yasm req to yasm 1.0.0 back when they added XOP asm and plenty of distros were still in 0.8.0 or so
[22:42:44 CEST] <JEEB> yeah
[22:42:57 CEST] <JEEB> http://up-cat.net/p/7f1bad2b
[22:43:07 CEST] <JEEB> but yeah, probably better to have not posted this :V
[22:46:12 CEST] <jamrial> JEEB: in any case, what Chloe is doing right now if i understood correctly is not duplicating the ffplay program into a new one but adding a copy of ffplay.c for sdl1 that will be compiled into the usual ffplay binary if sdl2 is not available
[22:46:54 CEST] <jamrial> which is cleaner than adding an stupid amount of #if preprocessor checks to get the same result
[22:48:01 CEST] <JEEB> that is true
[22:48:04 CEST] <Chloe> yep, the source file will just be switched depending on the sdl version, this may not be great in terms of backporting stuff, but I think it's the cleanest way to do it
[22:48:08 CEST] <Gramner> if someone is knowledgeable enough to want to build their own x264 (for example) instead of just using the distro-provided one they are most certainly able to build yasm as well. it also simplifies a lot of stuff to be able to ignore ancient versions of dependencies
[22:48:12 CEST] <Gramner> my 2 cents
[22:48:35 CEST] <jamrial> yeah
[22:52:37 CEST] <Chloe> Another topic to discuss, now that it seems a few people are actually here: The lavd API; I suggested having a discussion about looking into extending it. What are people's thoughts on this?
[22:53:29 CEST] <BBB> Chloe: I think we would never object out of principle, but wed need more specifics like how youd like to extend it
[22:53:46 CEST] <BBB> the primary reason lavd doesnt get a lot of attention is because most devs dont care
[22:54:09 CEST] <iive> depends what and how you want to extend.
[22:55:11 CEST] <jamrial> Nicolas seemed interested in not losing the sdl outdev before the sdl2 port was confirmed to work, so he evidently cares about lavd
[22:55:33 CEST] <Chloe> jamrial: he actually cared about the opengl device, not the sdl one
[22:55:58 CEST] <jamrial> ah. well, my point remains
[22:56:13 CEST] <durandal_170> I care about caca device
[22:57:10 CEST] <Chloe> I think that 'device' is currently not defined very well, it seems to be 'thing which interfaces with a library to perform I/O', but I feel the current API doesn't really fit the I/O part of the devices very well
[22:57:53 CEST] <durandal_170> lavd have no API, its lavf ripoff
[22:58:03 CEST] <Chloe> well yeah, that's kinda my point
[23:01:15 CEST] <Chloe> My idea would be to extend it to allow I/O commands and whatnot, but I'm struggling to think how this would work with the other parts of ffmpeg. For instance, what would happen to the output file if you rewinded a tape device input, would it output the input rewinding, or pause the output until the input starts 'playing' again. How would you handle device pauses? would it input black & no audio, or completely pause everything
[23:01:28 CEST] <durandal_170> Feel free to write new API, besides we don't care for libav api compatibility any more, do we?
[23:01:45 CEST] <JEEB> not that I know
[23:02:00 CEST] <JEEB> I mean, the libav compat option was mostly untested and I'm not sure if it ever worked
[23:06:19 CEST] <Chloe> How is OBJS-ffplay set? I cant seem to find it
[23:06:26 CEST] <Chloe> find how it's set*
[23:06:51 CEST] <jamrial> Chloe: by default all the programs add $prog.o
[23:07:01 CEST] <jamrial> look at the "define DOPROG" part in Makefile
[23:07:05 CEST] <BBB> Chloe: so, I think the key to most changes in ffmpeg (as a project) is that were open toa ny sort of changes, but it helps a lot to be more specific
[23:07:16 CEST] <jamrial> if you want to add extra sources, add a new OBJS-ffplay with it
[23:07:25 CEST] <BBB> Chloe: so once we have a specific idea of what youre trying to do, were happy to discuss specific design proposals
[23:07:55 CEST] <BBB> Chloe: and nothing is very official, its very informal and its supposed to be
[23:08:32 CEST] <jamrial> Chloe: so the ffplay target unconditionally compiles ffplay.c and unless you make some considerable changes you can't avoid that
[23:08:42 CEST] <iive> Chloe: how about make ffplay use outdev for output?
[23:08:56 CEST] <iive> i've heard that it have its own sdl code
[23:09:06 CEST] <Chloe> iive: the outdev doesnt work as you might expect
[23:09:18 CEST] <Chloe> it wont be able to take any inputs or events
[23:09:23 CEST] <BBB> good luck getting seeking to work
[23:09:25 CEST] <iive> well, fixing them is part of the fun :)
[23:09:27 CEST] <Chloe> due to it not having the main thread
[23:09:33 CEST] <BBB> (either picking up the seek, or executing it)
[23:09:35 CEST] <Chloe> iive: I dont really want to fix libsdl
[23:09:48 CEST] <Chloe> (sdl2 that is)
[23:09:58 CEST] <iive> i doubt that libsdl is the broken one.
[23:11:09 CEST] <iive> a lot of players implement their audio and video outputs, having generic ones might be useful.
[23:11:42 CEST] <jamrial> Chloe: what you could do is wrap the entirety of ffplay.c inside a HAVE_SDL2 check (after being ported)  to sdl2so compilation doesn't fail with sdl1. then add the sdl1 copy (ffplay-sdl1.o or whatever) to OBJS-ffplay-$(HAVE_SDL)
[23:12:25 CEST] <JEEB> I would say that if an OSS video renderer would be wanted the mpv opengl renderer should just be ripped into its own library or so, which has been noted before. it just needs someone doing the work.
[23:12:45 CEST] <JEEB> (videolan was open to utilizing such a library as well)
[23:13:05 CEST] <Chloe> iive: it's explicitly stated that sdl2 needs the main thread
[23:13:44 CEST] <Chloe> jamrial: good idea
[23:17:49 CEST] <Chloe> BBB: I dont have any design proposal at the moment, I just wanted to test the waters a little before getting started on it
[23:19:01 CEST] <BBB> Chloe: ok
[23:19:14 CEST] <BBB> Chloe: it makes it hard to comment in a specific way because Im not really sure where you want to go ;)
[23:20:19 CEST] <BBB> an opengl rendered sounds like a nice idea, dont forget small libraries are prone to die because big projects apply NIH and small maintainer teams tend to die out
[23:20:30 CEST] <BBB> but maybe it works, who knows :)
[23:25:50 CEST] <cone-938> ffmpeg 03Vittorio Giovara 07master:76c28360b561: vf_colorspace: Add modern names for color range option
[23:29:04 CEST] <BBB> I think I forgot to -s that patch, oops
[23:30:02 CEST] <Chloe> oh, I forgot to do that too a little while back, is it a problem?
[23:30:21 CEST] <jamrial> BBB: happens to me all the time
[23:30:26 CEST] <jamrial> Chloe: not really
[23:30:50 CEST] <BBB> maybe I should make -s default with doing git am
[23:31:04 CEST] <Chloe> I ended up putting [format] \n signoff = true in my git config
[23:31:20 CEST] <Chloe> I'm not sure if that signs stuff off before a push though
[23:35:24 CEST] <BBB> Ill have a look
[23:35:30 CEST] <BBB> need to go home first, thunderstorm incoming
[23:35:31 CEST] <BBB> brb
[00:00:00 CEST] --- Thu Sep 15 2016