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

[burek]

[09:58:03 CET] <cmeister2> hi. i'm interested in using ffmpeg to stream video from my Logitech C920 webcam. AFAICT it uses h.264 frames attached to an mjpeg stream, rather than exposing an h.264 stream. If I wanted to write an extension to ffmpeg so that it could split the mjpeg stream into mjpeg + h.264, what would the design for that look like? from my limited research so far i think it'd be a demuxer, but i'd appreciate an expert opinion
[09:59:10 CET] <cmeister2> (basically, doing https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad/html/gst-plugins-bad-plugins-uvch264mjpgdemux.html but in ffmpeg)
[09:59:46 CET] <JEEB> it would be a custom demuxer, yes. which would get somehow picked
[10:00:32 CET] <thardin> is mjpeg synonymous with something else here, or is there literally an mjpeg decoder? I thought it was just another word for intra-only with jpeg as the codec
[10:00:44 CET] <thardin> err mjpeg container of course
[10:01:33 CET] <cmeister2> i think it's mjpeg, but apparently there are extensions to mjpeg which allow you to attach arbitrary jfif frames
[10:01:45 CET] <cmeister2> something about APP0
[10:01:53 CET] <thardin> right jfif is a container unto itself as well
[10:03:06 CET] <cmeister2> it's the reason you see the errors here i think: https://stackoverflow.com/questions/55439184/getting-unable-to-decode-app-fields-while-playing-usb-webcam-stream-through-ff
[10:04:54 CET] <cmeister2> but thanks. knowing that it'll be a custom demuxer gets me a little closer.
[10:06:00 CET] <thardin> if you open a ticket for it and attach a dump of the webcam's output then perhaps more people can chip in
[10:06:15 CET] <thardin> plus it'd be tracked
[10:07:49 CET] <cmeister2> ok. i'll work out how to do that.
[10:11:52 CET] <JEEB> trac.ffmpeg.org basically
[10:49:17 CET] <Lynne> what time is the meeting on friday?
[10:51:21 CET] <kurosu> huh
[10:53:01 CET] <Lynne> wasn't there a meeting on the 6th? or was it the 8th
[10:53:42 CET] <JEEB> I don't think I've seen any announcement yet
[10:53:55 CET] <JEEB> I was going to bring it up if no announcement would happen
[10:58:00 CET] <kurosu> last I've heard was last Monday, but I don't think it happened
[10:59:25 CET] <kurosu> maybe because there was not enough priori notice
[11:00:15 CET] <JEEB> yes, the original message said, 1-2-3
[11:02:31 CET] <j-b> Goor morning people
[11:02:58 CET] <j-b> It'll be next Monday, because some people were not available. Sorry, my fault
[11:04:05 CET] <durandal_1707> Goor ray
[11:06:50 CET] <kurosu> Oh, so one could have asked to delay such a meeting. Nice to know
[11:07:44 CET] <durandal_1707> secdet meeting everdwhede
[11:08:06 CET] <j-b> nothing secret.
[11:11:17 CET] <durandal_1707> certainly secret for me, I always hear about it on irc and as last one
[11:16:53 CET] <j-b> You are invited, and you can join a call, like everyone.
[11:18:21 CET] <durandal_1707> i never received any notification, ecept once
[11:21:42 CET] <j-b> there was only one meeting, so that's good.
[11:22:00 CET] <j-b> I'll notify you personally if you want
[11:24:43 CET] <kurosu> First mail mentioning it was on 2019/10/14, meeting confirmed on the 6th of November, further detailed indeed in this channel on the 9th (depending on timezone), held on the 10th
[11:25:14 CET] <durandal_1707> i want to receive it via wire
[11:35:36 CET] <jdarnley_obs> What sort of wire?  A telegram?  Countries are starting to deprecate them now.
[11:35:49 CET] <stevenliu> timezone? Now here is 18:35:00 :D
[11:38:42 CET] <cmeister2> (trying to generate some appropriate video input right now)
[11:39:05 CET] <kurosu> jdarnley_obs: I here cloud is the new fad, so smoke signalling is probably what he needs
[11:43:34 CET] <stevenliu> Stream #0:0(und): Video: mjpeg (mp4v / 0x7634706D), yuvj422p(pc, bt470bg/unknown/unknown), 1920x1080, 64007 kb/s, 30.61 fps, 29.92 tbr, 1000k tbn, 1000k tbc (default)
[11:43:45 CET] <stevenliu> the video codec is mjpeg, not H.264
[11:45:45 CET] <JEEB> apparently there's some awful stuff that packs h.264 frames into mjpeg like stream, although I find that rather head-scratching :p
[11:46:25 CET] <cmeister2> i believe it's Logitech and maybe some capture cards that do similar things
[11:47:21 CET] <cmeister2> don't ask me why. they used to expose native H.264 video, but then in a revision of the camera apparently they started doing this weirdness
[11:49:37 CET] <stevenliu> Wow, 3D printer :D
[11:49:45 CET] <cmeister2> :)
[11:56:56 CET] <durandal_1707> tried radare2 with this braw program and it failed again, r2 is far from complete
[12:07:13 CET] <JEEB> durandal_1707: radare2 has unfortunately not had enough people bringing it to stability or features. classic open source problem when you're niche
[12:07:42 CET] <JEEB> and many people stop when they just notice it's broken for something they need (or crashes)
[12:07:58 CET] <JEEB> granted, until NSA's thing came along it was the only thing in open source for that :P
[12:12:28 CET] <durandal_1707> it there free download of 64bit windows? XP or Vista?
[12:12:58 CET] <JEEB> only 10 is officially freely avilable if you use a lunix UA
[12:13:09 CET] <JEEB> (otherwise it tries to feed you a downloader exe)
[12:13:24 CET] <JEEB> XP, vista, 7, 8.x all needed unofficial links to possibly official CDNs
[12:13:30 CET] <JEEB> digitalriver or whatever it was
[12:14:04 CET] <JEEB> (in other words, if you google for digitalriver windows VERSION (usually 7) you'd get results)
[12:14:11 CET] <JEEB> also there are windows VMs available from MS I think
[12:14:14 CET] <JEEB> those might still include 7
[12:16:06 CET] <durandal_1707> preferably torrent?
[12:16:16 CET] <durandal_1707> this it GB download
[12:16:36 CET] <JEEB> no official torrents and HTTPS has worked well so far from official CDNs
[12:16:41 CET] <durandal_1707> braw player is 64bit app, while i have only 32 bit VM vista
[12:17:03 CET] <durandal_1707> windows 7, or whatever it was called
[12:17:31 CET] <JEEB> check https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
[12:17:37 CET] <JEEB> they're officially for web testing
[12:17:40 CET] <JEEB> but I think they might not be that limited
[12:18:49 CET] <JEEB> oh, they're al 32bit :<
[12:18:52 CET] <JEEB> fug that
[12:19:03 CET] <JEEB> only the win10 one is 64bit
[12:19:57 CET] <JEEB> durandal_1707: if you search for "microsoft digitalriver windows 7" you'll probably find the 64bit iso :P
[12:20:21 CET] <JEEB> if you don't want the win10 one
[12:22:18 CET] <durandal_1707> but download is big and they never provide direct links
[12:22:33 CET] <durandal_1707> and i'm not on  fiber
[12:22:44 CET] <JEEB> I don't see how that makes any difference between p2p and non-p2p
[12:22:54 CET] <JEEB> and you do get a link there, no?
[12:23:09 CET] <durandal_1707> if connection breaks, i need to start over from 0
[12:23:10 CET] <JEEB> anyways, if you want to make it harder for yourself - check MSDN checksums and search for them
[12:23:24 CET] <JEEB> for the images you need that is
[12:23:32 CET] <JEEB> the MSDN checksums at least used to be freely available
[12:34:39 CET] <Illya> j-b: will you send a mail about next monday? I think that would be best to make sure everyone is informed
[12:35:19 CET] <durandal_1707> who is "everyone" ?
[12:35:48 CET] <JEEB> "the mailing list"
[12:35:53 CET] <JEEB> I would guesstimate
[12:36:01 CET] <Illya> everyone who needs to be informed, sending a mail to the list should catch that group
[12:38:39 CET] <Illya> And if you to be more specific: the general assembly, and anyone else who is interested to listen/contribute
[12:51:09 CET] <durandal_1707> JEEB: radare2 have bunch of nice features but its is very buggy at same time
[12:51:51 CET] <JEEB> durandal_1707: yes.
[20:18:10 CET] <kierank> durandal_1707: i can download and send you by post
[20:44:38 CET] <cone-121> ffmpeg 03Andreas Rheinhardt 07master:296f769fdca5: avformat/rmdec: Use av_packet_move_ref() for packet ownership transfer
[20:44:38 CET] <cone-121> ffmpeg 03Limin Wang 07master:0485033ae1dd: avfilter/vf_elbg: Fix for the seed type
[20:44:39 CET] <cone-121> ffmpeg 03hwren 07master:3003917a8fe0: lavc/libxavs2.c: use more descriptive variable names in xavs2_copy_frame* functions
[20:44:40 CET] <cone-121> ffmpeg 03hwren 07master:6721cd942ad6: lavc/libxavs2.c: avoid recomputations of pointers in xavs2_copy_frame* functions
[20:44:41 CET] <cone-121> ffmpeg 03hwren 07master:191203aa1fe1: lavc/libxavs2.c: fix code style - spaces
[20:44:42 CET] <cone-121> ffmpeg 03hwren 07master:0bafcc987458: lavc/libxavs2.c: optimize error descriptions
[20:51:44 CET] <durandal_1707> kierank: what?
[20:51:59 CET] <kierank> if you need big file download
[22:10:55 CET] <BBB> [hls @ 0x7fe885800600] pkt->duration = 0, maybe the hls segment duration will not precise, is there a ffmpeg flag to generate duration if it's not set by default in encoder/muxer?
[22:12:46 CET] <JEEB> not that I know, movenc tries to check if the muxer has the next packet already fed to it, I think?
[22:13:00 CET] <JEEB> but that's something that every muxer would have to attempt to do, which is a bit sub-optimal I guess
[22:13:59 CET] <JEEB> ff_interleaved_peek
[22:14:14 CET] <JEEB> seems to be what movenc is utilizing when flushing fragments
[22:14:57 CET] <JEEB> I think better option would be to have the encoder modules and such actually set the duration field in AVPackets
[22:16:04 CET] <Lynne> BBB: hlsenc generates the duration just after printing the warning
[22:19:15 CET] <BBB> oh ok
[22:24:11 CET] <JEEB> it doesn't appear to utilize peeking, so what this looks like it's just setting it to the pkt->pts - previous_end
[22:24:28 CET] <JEEB> vs->duration = (double)(pkt->pts - vs->end_pts) * st->time_base.num / st->time_base.den;
[22:26:21 CET] <Lynne> muxing/demuxing vfr hls would require some high level divine luck
[22:27:21 CET] <JEEB> sure, and generally the heaviest case is the end of clip
[22:27:41 CET] <JEEB> since while you can assume that frame was supposed to shown at the frame rate, but that can depend
[22:30:08 CET] <Lynne> that said, there's a high chance some chinese ip camera manufacturer does it anyway
[00:00:00 CET] --- Thu Dec  5 2019