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

[burek]

[00:40:23 CEST] <peloverde> BBB_ and anyone else who is interested: Demuxed talk proposals form is live http://demuxed.com/proposal-form
[00:40:35 CEST] <BBB_> anything youd like a talk on? :)
[00:40:40 CEST] <BBB_> Im happy to give a talk
[00:40:53 CEST] <BBB_> but vp9 may be getting old
[00:40:57 CEST] <BBB_> maybe I need to talk about something else
[00:41:33 CEST] <BBB_> bbl, date night tonight, Ill read responses later, email me
[00:42:04 CEST] <TD-Linux> maybe if I sign up to give a talk on my currently nonexistent GOP parallel encoder, I'll be forced to write it
[00:50:14 CEST] <peloverde> I still think something to the speed graphs at VDD2015 in Paris would be useful (e.g. calling out fake nextgen stuff instead of an "optimized transcode")
[04:20:28 CEST] <cone-853> ffmpeg 03Steven Liu 07master:363e4f0810d4: avformat/hlsenc: hold old key info when append list
[04:20:28 CEST] <cone-853> ffmpeg 03Steven Liu 07master:cbfd44a9229c: avformat/hlsenc: fix CID 1405135
[04:35:24 CEST] <BBB> peloverde: Ill think of something, how long do I have?
[04:36:31 CEST] <peloverde> until June 30
[04:42:07 CEST] <BBB> get your bossed to sponsor some studies I can do in that area ;)
[04:42:15 CEST] <BBB> Ill think about sutff :)
[04:42:22 CEST] <BBB> gnite for now, its late here
[10:53:20 CEST] <rcombs> what's the "mpegtsraw" demuxer for?
[10:57:21 CEST] <rcombs> looks like it used to be used for RTP, but isn't anymore?
[11:27:23 CEST] <nevcairiel> i never knew what it was really for
[11:28:27 CEST] <wm4> does the git history reveal anything?
[11:29:41 CEST] <BtbN> My guess would be it is to play mpeg-ts after it has been unpacked from its 144 byte packages?
[11:37:33 CEST] <sinanksu> hi
[11:37:57 CEST] <sinanksu> my forum password rest email not get
[11:39:02 CEST] <nevcairiel> we dont have a forum, you are in the w rong place
[11:40:43 CEST] <rcombs> anyone know a good way to extract an unknown stream from an MPEGTS (and just get the result in a file)?
[11:40:54 CEST] <sinanksu> http://ffmpeg.gusari.org/index.php
[11:40:56 CEST] <sinanksu> ?????
[11:41:01 CEST] <rcombs> could've sworn there was a muxer that took `bin_data` input and just dumped it
[11:46:32 CEST] <BtbN> if in doubt, hack it into the demuxer?
[11:46:37 CEST] <BtbN> shouldn't be overly hard
[12:53:22 CEST] <Compn> nevcairiel : yea we have a forum :D
[13:31:16 CEST] <nevcairiel> Compn: http://www.ffmpeg.org/contact.html "FFmpeg offers no official forum."
[13:31:17 CEST] <nevcairiel> :P
[15:48:19 CEST] <sinanksu> H0
[15:48:21 CEST] <sinanksu> GUYS
[15:48:55 CEST] <sinanksu> Who can help me.
[15:49:23 CEST] <wm4> nobody, go away, we don't do forums
[15:51:00 CEST] <sinanksu> No one found a problem in the forum.
[15:51:07 CEST] <J_Darnley> You haven't asked a (relevant) question yet.
[15:52:19 CEST] <sinanksu> I am getting a live stream in raw format with rtmpdump. Then I broadcast this live broadcast via rtmp with ffmpeg. But the live broadcast continues to freeze for 5 seconds. 5 seconds playing 1 second freezing, 5 seconds playing 1 second freezing, 5 seconds playing 1 second freezing. This is how the live broadcast progresses.
[15:52:20 CEST] <sinanksu> I searched, but I could not find a solution.
[15:52:20 CEST] <sinanksu> My current code.
[15:52:20 CEST] <sinanksu> rtmpdump -r rtmpe://xx.xx.xx.xx/live -a xlive -f WIN 23,0,0,162 -s httplink/VideoPlayer.swf -w dsa4d64as9d4as89d498as4d98a4sd894a89d4894s98d49asd a -x 585534 -p "http link" -C S:client -C S:3.1.0.10 -C S:en --live -y raw:999999 | ( ffmpeg -re -i - -sn -vcodec copy -acodec copy -f flv rtmp://127.0.0.1:1935/restream/999999 ) 
[15:52:23 CEST] <wm4> we don't provide user support either
[16:54:28 CEST] <BBB> peloverde: ping
[17:20:36 CEST] <peloverde> BBB: pong
[17:21:54 CEST] <BBB> peloverde: so lets hypothetically assume I talk about quality in vp9/hevc/h264/&, what is the current level of interest in that area of the sphere in terms of video codecs?
[17:22:09 CEST] <BBB> should I talk about av1?
[17:22:15 CEST] <BBB> how many people still use h264?
[17:22:22 CEST] <BBB> is hevc already/finally dead?
[17:23:56 CEST] <peloverde> lots of people still use h.264, some people are still hype for hevc but i haven't seen new big deployments recently, there is interest in av1 but obviously it's not ready yet
[17:23:57 CEST] <BBB> are there other talks about video codecs?
[17:24:10 CEST] <BBB> are you planning to talk about av1?
[17:27:15 CEST] <peloverde> nothing has been accepted yet, I've thought about putting something in on av1 but might sit this one out or encourage someone else to do one
[17:28:13 CEST] <Fenrirthviti> BBB: I can say from a livestreaming standpoint, the capabilities of vp9 and av1 are a hot topic (unless that's completely off topic for what you're referring to)
[17:29:50 CEST] <BBB> av1 live streaming ;)
[17:31:04 CEST] <iive> i haven't even heard of av1
[17:31:21 CEST] <Fenrirthviti> It's the AOMedia encoder
[17:31:42 CEST] <durandal_1707> isnt av1 sloooow when encoding?
[17:31:51 CEST] <gnafu> Built on VP10 using techniques from Daala and Thor.
[17:32:00 CEST] <gnafu> durandal_1707: No worse than H.265 while it was being standardized ;-).
[17:32:03 CEST] <iive> is it using some of the existing standard codecs, or does its own thing?
[17:32:11 CEST] <Fenrirthviti> They supposedly have an entire spec in the codec dedicated to the livestreaming side of things.
[17:32:26 CEST] <BBB> oh no :(
[17:32:31 CEST] <BBB> peloverde: please fix that ;)
[17:32:40 CEST] <BBB> (or is that just not true?)
[17:32:59 CEST] <BBB> I dont want another h264 with cavlc/cabac etc.
[17:33:14 CEST] <gnafu> Several of the Alliance members are focused on live streaming and video conferencing (Cisco, Bitmovin, etc.).
[17:33:31 CEST] <gnafu> I don't think it's so much a separate code path; more just making sure there's a mode that will work in those cases.
[17:33:47 CEST] <Fenrirthviti> Bitmovin just announced their product has av1 support a few weeks ago
[17:33:53 CEST] <gnafu> s/code path/spec or whatever/
[17:33:56 CEST] <peloverde> no, there aren't going to be pluggable components a la 264 or 263
[17:34:02 CEST] <BBB> pheew
[17:34:25 CEST] <Fenrirthviti> https://bitmovin.com/bitmovin-supports-av1-encoding-vod-live-joins-alliance-open-media/ their presser on it
[17:34:59 CEST] <Fenrirthviti> with such buzz phrases as "Optimized for the Internet" :p
[17:35:35 CEST] <RiCON> bitmovin blogs are all 80% buzz phrases
[17:35:55 CEST] <Fenrirthviti> But 77 experimental encoding tools!
[17:36:08 CEST] <Fenrirthviti> sorry, coding, not encoding.
[19:34:56 CEST] <kierank> 8:32 AM <Fenrirthviti> They supposedly have an entire spec in the codec dedicated to the livestreaming side of things.
[19:35:04 CEST] <kierank> that's a bit of a misunderstanding
[19:58:56 CEST] <JEEB> lawl
[20:14:29 CEST] <TD-Linux> Fenrirthviti, BBB, no there is no separate "live" mode
[20:16:16 CEST] <gnafu> Even the good/realtime distinction is going away (compared to VP9).
[20:16:26 CEST] <gnafu> Which I'm excited about ;-).
[20:17:47 CEST] <TD-Linux> that was a libvpx implementation detail fwiw
[20:27:05 CEST] <Fenrirthviti> kierank: yeah, I should say that live streaming was a large consideration during the design. Poor choice of words.
[20:35:03 CEST] <gnafu> TD-Linux: Yeah, I s'pose that's outside of the realm of standard/spec.
[20:36:24 CEST] <cone-928> ffmpeg 03Muhammad Faiz 07master:e061826eb2a5: avfilter/lavfutils: use image2pipe demuxer on ff_load_image
[20:56:01 CEST] <alevinsn> jkqxz:  I'll look at what you posted earlier later
[20:56:09 CEST] <alevinsn> just now saw your message when I scrolled up
[21:00:58 CEST] <jkqxz> alevinsn:  Sure.  I'm happy to just apply it whenever, but you should probably look at it again before I do.
[21:01:25 CEST] <wbs> mateo`: just fwiw, there's no need to use gas-preprocessor for building ffmpeg for ios prior to your simple_idct stuff
[21:02:02 CEST] <wbs> mateo`: so instead of starting mandating the use of gas-preprocessor, I would recommend trying to fix it so that it doesn't break on clang's built in assembler. janne worked hard to make sure that we don't need gas-preprocessor for aarch64 in libav
[21:02:31 CEST] <wbs> mateo`: gas-preprocessor is detected and enabled automatically for armv7 (where it needed), but not for aarch64
[21:04:29 CEST] <durandal_1707> kierank: how to blink one frame every second for noninteger framerate?
[21:25:39 CEST] <mateo`> wbs: my bad, I was not aware that gas-preprocessor was not mandatory for aarch64. I'll fix it. It won't be until 2 weeks unfortunately (as i won't have an apple machine at hand for the next week).
[21:27:05 CEST] <mateo`> I guess, I'll re-open the trac ticket
[21:28:59 CEST] <wbs> mateo`: in general, clang has improved their internal assembler quite a lot; there's more or less just one feature missing for it to be able to build our arm assembler without gas-preprocessor as well
[21:30:17 CEST] <mateo`> ok
[21:32:17 CEST] <mateo`> wbs: do you know if there is some documentation listing the limitations of their assembler ?
[21:32:34 CEST] <JEEB> so most likely armv7 will continue requiring gas?
[21:34:14 CEST] <wbs> mateo`: not really, just try to avoid odd things, be strict with using commas between all macro parameters, etc
[21:35:07 CEST] <wbs> JEEB: unless they get to implementing altmacro support, but that's a pretty hairy thing
[21:42:20 CEST] <mateo`> wbs: i guess the issue is that i don't have used comas to separate arguments in macros
[23:19:29 CEST] <ubitux> mateo`: wbs: can't we make gas be more pedantic and warn/error out on these "exotic" syntax abuses?
[23:22:34 CEST] <wbs> ubitux: I don't know of any such options unfortunately - gas is rather bare-bones
[23:23:11 CEST] <wbs> ubitux: it's more like, for gas it is strictly correct syntax, but clang only implements a "sane simple subset" of it, pretty much
[23:23:47 CEST] <wbs> you should be able to find the same issues if you build with clang for linux as well, no need for a ios toolchain
[23:24:18 CEST] <ubitux> ok
[23:24:53 CEST] <wbs> and like, strictly speaking, one could say screw clang and just use gas-preprocessor, but there's some value in sticking to whatever subset clang happens to work with
[23:35:39 CEST] <ubitux> yeah sure, i agree with that
[23:36:21 CEST] <ubitux> though, if it only affects aarch64, it's likely ppl will have gaspp anyway for the arm build as well
[00:00:00 CEST] --- Sat Apr 29 2017