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

[burek]

[01:32:19 CET] <keegans> when using the hls api i can only get the samples from the first stream
[01:32:27 CET] <keegans> how can i select which stream I'd like to get samples from?
[01:32:34 CET] <keegans> or are they tracks? (each segment in the HLS stream )
[01:39:56 CET] <keegans> is this a bug or am i misunderstanding the code : https://github.com/FFmpeg/FFmpeg/blob/32fb83e4318845a7f44f7bed02d5963b9e81804e/libavformat/hls.c#L1926 ?
[01:40:24 CET] <keegans> because my current issue is that av_read_frame only gives me the samples in the first segment of the HLS file
[01:59:56 CET] <keegans> k , i'll be back and fix this bug
[08:24:44 CET] <linux_gnu> Hi ,how can I use ffmpeg to record the audio from my audio card ,like if i m listenning to a web radio???thanks
[08:45:17 CET] <linux_gnu> or how to use ffmpeg to record the desktop in video and the sound from the mike??
[09:00:49 CET] <linux_gnu> anyone?
[11:53:35 CET] <BtbN> Can ffprobe give me the exact duration somehow? Even if that means decoding the whole thing?
[12:04:51 CET] <furq> maybe -count_frames
[12:05:31 CET] <JEEB> BtbN: -show_frames and then the PTS of the last frame + duration if it's there
[12:05:47 CET] <JEEB> that of course differs by stream a bit
[12:06:15 CET] <JEEB> and since some streams begin from nonzero you might need to also take into account first frame's PTS
[12:19:44 CET] <BtbN> I resorted to parsing the time= output of ffmpeg -i bla.mkv -f null -
[12:20:42 CET] <JEEB> but yea, if you don't have discontinuities max((last_pts - first_pts) + last_duration)
[12:20:58 CET] <JEEB> should be good enough and the -of json is useful to just push it to python or something
[12:22:14 CET] <BtbN> This is randomly cut mpegts
[12:22:29 CET] <BtbN> decoding it is really the only reliable source of its duration
[12:22:34 CET] <JEEB> yes
[12:22:42 CET] <JEEB> and -show_frames decodes
[12:22:51 CET] <JEEB> so you don't have to care about b-frames etc
[12:23:04 CET] <BtbN> Yeah, but the pts can be all over the place
[12:24:12 CET] <JEEB> in what sense? discontinuities, yes you have to handle those separately if the lavf side doesn't handle that wrap-around for you (IIRC it does the first time and then it bugs out).
[12:24:42 CET] <JEEB> but generally just having a nonzero start pts isn't a problem
[12:24:45 CET] <BtbN> It can be a concatenation of unrelated segments. So pts can jump, reset, and so on
[12:26:02 CET] <JEEB> yup, so that requires just having to handle that somehow :P remember that ffmpeg.c isn't perfect with that either, it's given me 10s A/V desync because it couldn't believe something really wanted to have nothing'ish for 10 seconds and then come back
[12:26:41 CET] <JEEB> you will get a value and it might handle some stuff. which might or might not be good enough for you
[12:27:52 CET] <BtbN> it seemed on point for everything I tested
[15:15:52 CET] <BtbN> This is probably the most insane script I ever came up with, but it seems to work: https://github.com/esamarathon/esaupload/blob/master/tools/combine_video.sh
[18:13:14 CET] <jemius> Hey folks. I'm doing a project where a rasperryPi-camera is used to observe something 24/7. I'm planning to use a video codec to archieve the pictures efficiently. Now I'm experimenting with ffmpeg and am a bit overwhelmed by all the options you can set. For example: "cat *.jpg | ffmpeg -f image2pipe -i - -c:v libx265 output.mkv"  the codec makes a very short video if it's 120 pictures. If I wanted to make a photo every 0.5
[18:13:14 CET] <jemius> s and create a storage video for each minute observation-time (so 120 pictures) and want ffmpeg to produce a video that's (of course) 60s long, how'd i do that? I tried to enforce this with the framerate, but it caused very large videos and I don't really understand why, as even a 40 hour long video containing 120 pictures should only be as large as the 120 pics
[18:18:49 CET] <sparrowrsword> how do i compress a lossless avi file down to something reasonable? its an 8 gig file... and its only a few minutes long at most... was trying to upload a video to youtube and used obs to record, however for some reason the last video i recorded was 360p, which is unwatchable...so i recorded in lossless
[18:23:46 CET] <sparrowrsword> https://unix.stackexchange.com/questions/60042/trying-to-compress-avi-file-using-ffmpeg
[18:24:22 CET] <JEEB> pretty sure the trac wiki has stuff on x264, which is so far the best practice of how to encode stuff :P
[18:24:30 CET] <JEEB> with it having relatively straightforward knobs
[18:24:37 CET] <JEEB> preset for "how fast does this train go"
[18:25:08 CET] <JEEB> and then CRF for variable bit rate control that could be sumamrized as being the least far from being "constant quality" kind of thing, without actually being such
[18:25:31 CET] <JEEB> https://trac.ffmpeg.org/wiki/Encode/H.264
[18:25:44 CET] <JEEB> yup, so I don't have to repeat my usual lines (possibly)
[18:29:58 CET] <Blacker47> jemius, you need to set the framerate (maybe both, for input and output).
[20:35:59 CET] <jemius> Blacker47: Well, that still results in a larger movie. And I don't know why
[20:40:05 CET] <Blacker47> jemius, video is build of independend GOPs each of that starts with a I-Frame that has complete frame (compressed like jpeg). the number of frames a GOP can have is limited (say it is 60 or 120 maybe much less depending on setting). that you can try is very low output framerate and a large GOP. i don't know if framerate can go below 1.
[20:40:50 CET] <Blacker47> in general it makes no sense to create a such long video for only 120 pictures.
[20:41:26 CET] <JEEB> technically frame rate can be whatever as long as it can be coded in the time base required
[20:42:37 CET] <Blacker47> even if strange framerate can be used for encoding a player may not be able to handle it... needs testing.
[20:42:52 CET] <klaxa> practically, i've had problems with framerates near and below 1 during playback (mpv)
[20:56:45 CET] <jemius> GOP?
[20:57:00 CET] <jemius> So how do I find out what's the optimal solution for my scenario?
[21:17:08 CET] <Blacker47> Group Of Pictures.
[21:17:47 CET] <Blacker47> jemius, maybe there is some, but i don't know what codec is suitable for such a pathetic scenario...
[21:44:34 CET] <jemius> Don't call the dreams of my life pathetic :O
[21:47:46 CET] <Blacker47> jemius, it is easier to write a program/script that will change to the next picture every 20 minutes.
[21:49:43 CET] <jemius> Blacker47: Probably; the video length isn't my concern. My concern is compression. I just came up with the length issue by the observation of changing video sizes depending on the frame rate
[21:59:08 CET] <LigH> Hi.
[21:59:57 CET] <LigH> Do you already know of https://github.com/OpenVisualCloud/SVT-VP9 - and may it be supported in ffmpeg some day, if not already?
[22:00:53 CET] <jemius> LigH: Doesn't AV1 make VP9 obsolete?
[22:01:03 CET] <LigH> It's already mentioned in https://www.freshports.org/multimedia/svt-vp9/ but I did not yet check other commit lists...
[22:01:21 CET] <LigH> Some prefer high speed over best quality.
[22:01:55 CET] <LigH> This encoder claims to be able to encode in real time, if I understood correctly.
[22:03:27 CET] <JEEB> libvpx also can do real-time
[22:03:43 CET] <furq> most things can do realtime if you murder the quality badly enough
[22:03:58 CET] <JEEB> anyways, we should see people testing that one soon enough
[22:04:08 CET] <JEEB> then we'll see if there's any interest in adding a wrapper for it
[22:05:44 CET] <jemius> The newest version of ffmpeg already supports AV1, is that correct?
[22:05:57 CET] <furq> yes
[22:06:00 CET] <furq> libaom-av1
[22:06:01 CET] <durandal_1707> via wrappers
[22:06:18 CET] <jemius> The codec is said to be really slow still, though
[22:06:33 CET] <JEEB> for decoding it should be fast enough with dav1d
[22:06:40 CET] <JEEB> encoding is slow though, yes
[22:06:49 CET] <JEEB> although the same SVT-* thing is also available for AV1
[22:09:29 CET] <LigH> Indeed: https://github.com/OpenVisualCloud/SVT-AV1
[22:11:28 CET] <LigH> So I will have some patience and assume that future support is probable.
[22:11:38 CET] <LigH> :)
[22:11:43 CET] <JEEB> we'll see
[22:11:51 CET] <LigH> Bye.
[22:20:08 CET] <jemius> How come we can use HEVC freely yet? I thought there are huge license fees on that one
[22:20:25 CET] <JEEB> open source generally doesn't take comments on that
[22:20:52 CET] <JEEB> f.ex. FFmpeg only provides the source code, if you when distributing a binary are under a need to pay royalties - that's a separate thing
[22:21:16 CET] <JEEB> same for VLC f.ex. although they're based in France and have counted that they don't need to care about the licenses
[22:21:40 CET] <JEEB> IANAL (I Am Not A Lawyer) and thus I recommend that if you care you may have to look into these things
[22:22:08 CET] <kepstin> jemius: it's basically "you're responsible for finding out what patent licensing / fees apply to you"
[22:22:47 CET] <jemius> kepstin: So no one bothers if open source folks distribute programs able to en/decode HEVC?
[22:23:09 CET] <Mavrik> Em.
[22:23:15 CET] <Mavrik> Noone is stopping you from doing that.
[22:23:26 CET] <JEEB> distribute source and distribute binaries are two very different things
[22:23:33 CET] <Mavrik> But noone will stop the patent pools from suing you to hell and back either :)
[22:24:02 CET] <jemius> Well, I get ffmpeg as a binary through debian or arch, so I don't see the difference
[22:24:21 CET] <JEEB> in that case debian/arch handle the binary distribution
[22:25:16 CET] <kepstin> those distributions own legal teams have decided how to handle that.
[22:25:24 CET] <JEEB> yup
[00:00:00 CET] --- Mon Feb 18 2019