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

[burek]

[00:04:10 CET] <JEEB> ok, and I just reminded myself that there are indeed various duration fields in matroska
[00:04:35 CET] <TikityTik> how am i able to spoof the duration of a webm? I tried changing some stuff around, but no luck
[00:05:07 CET] <JEEB> set the BlockDuration of the last sample to a very large value?
[00:05:19 CET] <JEEB> and then amend SegmentDuration similarly I guess
[00:05:27 CET] <JEEB> that way the actual duration of the file becomes that
[00:05:55 CET] <JEEB> I think that should be doable with libavformat by passing an AVPacket of the last sample with a long enough duration set
[00:06:19 CET] <JEEB> that should work automagically if the muxer writes those values
[00:06:27 CET] <TikityTik> i'm trying to get the file to have lower duration metadata than the actual length
[00:08:07 CET] <JEEB> making the segment's duration not match what the samples contain? although to be honest anything will most likely find the correct duration unless segment duration is the playlist duration in which case the last parts just get cut off
[00:08:20 CET] <JEEB> not sure how parsers understand such a mismatch
[00:08:23 CET] <TikityTik> so it's not possible?
[00:08:43 CET] <JEEB> well every track's every sample will have a timestamp and a possible duration
[00:08:50 CET] <JEEB> so if you parse the packets you will get the correct length
[00:09:05 CET] <JEEB> there is a segment duration for the overall segment (contents of the file more or less)
[00:09:15 CET] <JEEB> but as I noted, most things will then parse the contents
[00:09:25 CET] <JEEB> not sure what you're trying to do :P
[00:09:35 CET] <TikityTik> well there's a website that limits video files not only on filesize, but duration too
[00:09:56 CET] <JEEB> just don't use it then
[00:10:15 CET] <TikityTik> hahah, i want to see if i can get it work on there
[00:10:43 CET] <JEEB> I mean, you could try creating multiple segments in a single file (cutting the video into parts effectively), but that also breaks playback and if they remux you will most likely just get the latter segment cut off
[00:11:01 CET] Action: JEEB sighs
[00:11:24 CET] <TikityTik> lol
[00:11:27 CET] <JEEB> I've given you a few options of breaking your file
[00:11:52 CET] <JEEB> either modify the segment duration (overall duration flag) or put multiple segments into a single file
[00:12:23 CET] <JEEB> and I cannot wait until someone comes crying for support for such broken files
[00:12:30 CET] <JEEB> fuck hell this world is
[00:12:41 CET] <JEEB> (and I cannot type)
[00:13:14 CET] <TikityTik> LOL
[00:39:23 CET] <TikityTik> ahahah, nice it works
[00:40:49 CET] <JEEB> TikityTik: which piece of crap did you try?
[00:41:04 CET] <TikityTik> JEEB: in the code?
[00:41:46 CET] <JEEB> no, I mean - which of the two ways you tried :P
[00:42:42 CET] <TikityTik> changing the mux's duration
[00:43:10 CET] <JEEB> the one in the segment info?
[00:44:16 CET] <TikityTik> mkv_write_packet_internal
[00:44:29 CET] <TikityTik> not sure which one that is
[00:46:22 CET] <JEEB> if that's for each sample then rip, that thing just makes the thing much faster if you make it smaller
[00:46:27 CET] <JEEB> as in, effectively breaks playback
[00:46:43 CET] <JEEB> not like the duration field changing not being able to break stuff, or the multiple segments thing
[00:47:03 CET] <JEEB> you might as well in that case though just modifying the timestmaps of the AVPacket
[00:47:08 CET] <JEEB> instead of patching matroskaenc
[00:47:19 CET] <JEEB> since you just want to make the file faster
[00:49:24 CET] <plexigras> ERROR: gnutls not found using pkg-config
[00:49:28 CET] <plexigras> what do i do?
[00:49:52 CET] <TikityTik> https://ptpb.pw/yYfU
[00:50:00 CET] <TikityTik> works for me
[00:50:33 CET] <JEEB> well yes, I'm just saying that you just made it faster, no? unless you changed the code there that somehow affects the segment's duration
[00:51:15 CET] <JEEB> also why the hell is it blindly copying the ISOBMFF metadata from the input, hah
[00:52:12 CET] <TikityTik> it's not faster, it plays normal
[00:52:29 CET] <JEEB> then you didn't modify the actual packet durations
[00:52:40 CET] <JEEB> and/or your defaultduration is correct and there are no durations in the blocks
[00:53:01 CET] <JEEB> while you have written something bogus in the segment duration and it's effectively getting ignored :)
[00:57:14 CET] <plexigras> i have gnutls already install
[00:58:15 CET] <TikityTik> How can I get reduce video bitrate if the video is from a looping gif?
[00:58:30 CET] <TikityTik> is it possible or would it still be like a regular video's bitrate?
[00:58:51 CET] <JEEB> well with a good encoder and a long enough forced GOP it should compress nicely
[00:58:52 CET] <TikityTik> i would assume ffmpeg can have very low bitrate size for something that loops and follows a pattern
[00:59:00 CET] <TikityTik> forced GOP?
[00:59:00 CET] <JEEB> unfortunately not sure how well libvpx handles it
[00:59:27 CET] <JEEB> -g XXX -x264-params "scenecut=0"
[00:59:31 CET] <JEEB> for x264
[00:59:36 CET] <JEEB> where XXX is the value which sets keyint to infinite
[00:59:37 CET] <TikityTik> utilizing libvpx
[00:59:39 CET] <JEEB> it's either -1 or 0
[00:59:45 CET] <JEEB> TikityTik: that's the problem as I noted
[00:59:54 CET] <JEEB> no idea how well that one works with this kind of stuff
[01:00:09 CET] <JEEB> if it's a use case that GOOG didn't care about, it's not there
[01:00:26 CET] <JEEB> but I guess you can try seeing if it has an infinite gop mode
[01:00:46 CET] <JEEB> and/or setting the length to just something long and hoping it is able to utilize that
[01:00:58 CET] <JEEB> it's just very possible that libvpx is not good enough for that
[01:01:05 CET] <JEEB> -g sets the GOP length
[01:01:43 CET] <TikityTik> what is GOP?
[01:01:58 CET] <JEEB> group of pictures
[01:02:11 CET] <JEEB> usually meant as somethign that has a RAP (Random Access Point) at the beginning
[01:02:22 CET] <JEEB> until the image before the next one
[01:02:25 CET] <TikityTik> so i would want -gop 0 or -1?
[01:02:37 CET] <JEEB> no idea what values libvpx wrapper takes as infinite
[01:02:43 CET] <JEEB> it 100% depends on the encoder
[01:03:08 CET] <JEEB> and if the wrapper just passes it on as-is, then you have to look it up in libvpx
[01:04:21 CET] <TikityTik> static const AVCodecDefault defaults[] = {    { "g",                "-1" },... libvpxenc.c
[01:04:37 CET] <JEEB> that's just the default then
[01:04:41 CET] <JEEB> if you don't set it
[01:04:50 CET] <TikityTik> but i don't know what -g value i want
[01:05:02 CET] <JEEB> yes, you have to look at what the init function does
[01:05:22 CET] <JEEB> if it doesn't something with the gop length
[01:05:26 CET] <JEEB> *does something
[01:05:40 CET] <JEEB> and if it just passes things on, then you will have to take a look in libvpx itself
[01:11:37 CET] <TikityTik> But what GOP value am I aiming for? the same amount of frames there are in a gif?
[01:13:33 CET] <JEEB> TikityTik: well it will never be as optimal as a palette coded GIF that has a flag for looping, but if you basically make an unseekable file where there's only one random access picture it should compress nicely with any sane encoder
[01:13:53 CET] <JEEB> the idea is that if you make it long enough it should find the exact same picture and compress it very well within the same GOP :P
[01:14:04 CET] <JEEB> which is why you need to find the thing that sets it to "infinite"
[01:14:48 CET] <JEEB> as I noted, that is encoder specific and I don't even know if libvpx has the capability of knowing that in its encoder buffer
[01:20:36 CET] <TikityTik> i'm sure -g -1 is infinite
[01:20:53 CET] <TikityTik> since i seen the bitrate change dramaticall from -g -1 to -g 10
[01:25:27 CET] <JEEB> TikityTik: or it might just be the default for frame rate * 10 or something
[01:25:35 CET] <JEEB> I think libx264 for example defaults to 240 or so
[01:25:44 CET] <TikityTik> why don't i juse use -g 999999999999 then?
[01:25:58 CET] <JEEB> you can do that just fine if libvpx is OK with that
[01:26:13 CET] <JEEB> I mean, I did note that thing as well if there was no "infinite" option in libvpx itself
[01:28:21 CET] <TikityTik> yeah i set it to -g 99999999999
[01:28:28 CET] <TikityTik> and the filesize being the same as -g -1
[01:28:34 CET] <TikityTik> ended up being the same as*
[01:31:08 CET] <JEEB> then it might just not be good at utilizing the GOP length
[01:31:21 CET] <JEEB> if you had a VP8 bit stream checker you could see how it codes those duplicates
[01:35:37 CET] <SortaCore> wellp
[01:35:49 CET] <SortaCore> you know it's good code when you have 20 ternary statements in it
[01:52:21 CET] <TikityTik> how can I get audio and video to be synced when I cut from a video source where I also did -c copy?
[01:52:36 CET] <TikityTik> my audio is playing before the video plays and i can't encode this file
[02:22:57 CET] <TikityTik> Does -auto-alt-ref, -lag-in-frames, -frame-parallel, increase size?
[02:37:01 CET] <TikityTik> Also how can i calculate the optimal video dimensions and fps for a bitrate?
[02:41:25 CET] <SortaCore> pixels_per_row * num_rows * bits_per_row * fps  == bitrate
[02:41:40 CET] <SortaCore> too many unknowns :p
[02:41:55 CET] <TikityTik> wait, what option specifices pixels per row for vp8?
[02:42:12 CET] <SortaCore> video width
[02:42:21 CET] <SortaCore> <.<
[02:42:45 CET] <TikityTik> i mean
[02:42:47 CET] <SortaCore> bits per row changes if your codec can compress nicely
[02:43:03 CET] <TikityTik> eh?
[02:43:17 CET] <SortaCore> ...this won't make any more sense how I explain it
[02:43:30 CET] <SortaCore> but too many values for a flat formula, anyway
[02:44:01 CET] <TikityTik> ok well lets say i know what bitrate and fps I can go to
[02:44:13 CET] <TikityTik> how can i calculate if my dimensions will look bad?
[02:44:13 CET] <SortaCore> normally you just pick best dimensions, pick best fps, then fuss about how well you want it to compress (bitrate or variable quality)
[02:44:50 CET] <SortaCore> try and work out minimal bits needed per pixel to ensure good quality
[02:44:58 CET] <SortaCore> and it's extremely vague due to compression
[02:45:10 CET] <SortaCore> so... don't bother
[02:45:28 CET] <SortaCore> I'd just use variable quality instead of fixed bitrate
[02:45:41 CET] <TikityTik> i have a maximum filesize
[02:46:23 CET] <SortaCore> for variable it'll do better for easily-compressed data
[02:46:30 CET] <SortaCore> for fixed it'll stay the same regardless
[02:46:57 CET] <SortaCore> wb
[02:48:22 CET] <SortaCore> wb again?
[02:48:37 CET] <TikityTik> which is why i want to calculate optimal dimensions
[02:49:02 CET] <SortaCore> you'd have to reverse the formula it uses to get bits per pixel
[02:49:23 CET] <SortaCore> and then retain ratio of source width : height
[02:53:15 CET] <TikityTik> which one was bits per pixel? I see bits per row
[02:54:10 CET] <SortaCore> roughly bits_per_row / video width
[02:54:46 CET] <TikityTik> so how many bits per pixel is considered good?
[02:57:37 CET] <SortaCore> you'll just have to trial-and-error it
[03:25:52 CET] <TikityTik> are you able to get lower bitrate than 8kbps for libvorbis?
[03:34:42 CET] <TikityTik> when i'm doing 2 pass, do i have to calculate -pass 1 eachtime I change an option?
[03:34:51 CET] <TikityTik> or is it just dependent if the input is different?
[03:37:53 CET] <DHE> it's usually fine to use the same pass1 stats file if you're just tweaking options, but only to a point. for video some options like number of bframes or GOP-interval can't change
[03:39:41 CET] <TikityTik> so what about changing the scaling and framerate and bitrate?
[03:40:38 CET] <DHE> bitrate is usually safe. framerate is just a special case of bitrate because it's all a measure of "bits/frame" with a time factor to be eliminated in the calculation.
[03:41:03 CET] <DHE> scaling is where it starts getting tricky. in some ways it's not the same input video, and in some ways it is.
[03:41:33 CET] <TikityTik> DHE: i mean i adjust scaling of the output for pass 2
[03:41:41 CET] <TikityTik> not the scaling of the input
[03:53:47 CET] <DHE> I'm not familiar with that setting
[06:37:24 CET] <TikityTik> what's the variable called for the muxer that holds metadata for the bitrate?
[07:42:55 CET] <TikityTik> where is a video's bitrate written?
[08:16:49 CET] <ajbone> Hello, I'm attempting to record my desktop with audio in ubuntu linux, the other running system processes are a web browser with a java based video plugin. The video plays continously when not recording but it seems to crash or get stuck buffering at about 10 minutes into my planned recording time of 1 hour. I have tried simplescreenrecorder and switched from debian to ubuntu to try OBS, everything I try has about the same result. I have a 250GB H
[12:48:17 CET] <faLUCE> hello. not a totally-ffmpeg question but... how can I check if a MPEGTS PES packet contains a H264 keyframe?
[13:07:48 CET] <DHE> as in, using libavcodec and libavformat?
[13:08:56 CET] <faLUCE> DHE: yes, I could use them
[13:09:52 CET] <DHE> I'm asking for context. how do you have this MPEGTS PES packet by itself?
[13:10:18 CET] <faLUCE> I get it from another library (gstreamer) as char* array
[13:10:24 CET] <JEEB> not to mention that with open gop you would also have the SEI, not only the NAL unit :P
[13:10:43 CET] <JEEB> because AVC didn't have open GOP keyframes as a single NAL
[13:11:02 CET] <DHE> well for a regular keyframe and MPEG-TS, the first chunk (184 bytes) would have the MPEG-TS header bit RAI (random access indicator) flagged as TRUE
[13:11:14 CET] <DHE> assuming you've verified this is an H264 chunk
[13:11:56 CET] <faLUCE> DHE: about that, I could only verify if the chunk is video... or is there a way to check if it is H264 ?
[13:12:13 CET] <DHE> the PMT has a single byte as a codec indicator. check that its value is whatever indicates H264
[13:12:36 CET] <faLUCE> DHE: but PMT and PES are different packets
[13:12:42 CET] <DHE> this should be handled by your library, like libavformat for ffmpeg
[13:15:31 CET] <faLUCE> I found that:  https://stackoverflow.com/questions/18742683/detecting-i-frame-data-in-an-mpeg-4-transport-stream   <--- it says to check if the packet is a video packet (pid == video_pid )
[13:15:46 CET] <faLUCE> but I don't understand where to get the video pid.
[13:15:54 CET] <JEEB> PAT=>PMT=>you know the PID
[13:16:01 CET] <JEEB> PAT is always 0x00 PID I think?
[13:16:10 CET] <DHE> I believe so yes
[13:16:19 CET] <DHE> but still, are you doing MPEGTS parsing yourself?
[13:16:25 CET] <DHE> I mean, it's not hard but still
[13:17:45 CET] <faLUCE> I thought there is an easier way...
[13:18:33 CET] <DHE> there is in the protocol. but if you can't read the PMT and MPEG-TS headers then you'll have to go through whatever hoops your handling library provides to find it
[14:18:27 CET] <faLUCE> JEEB: you wrote: PAT=>PMT ... what do I have to check in PAT that I have to check in PMT then?
[14:19:38 CET] <JEEB> PAT has indices of the PMTs for different programs, PMT has the PIDs for a program
[14:19:51 CET] <JEEB> it's standard MPEG-TS demuxing
[14:20:10 CET] <JEEB> you find a PAT, you find a PMT of the program you care about, you start demuxing PIDs for that program
[14:20:35 CET] <faLUCE> JEEB: I have only one program in my stream
[14:20:49 CET] <faLUCE> So I could check only the PMT
[14:21:29 CET] <JEEB> you still need to know which PID the PMT is in
[14:21:32 CET] <JEEB> :P
[14:21:38 CET] <JEEB> PAT tells you that
[14:23:19 CET] <faLUCE> I don't understand. I need the video_PID. so I should only need the PAT
[14:23:48 CET] <DHE> a broadcast can contain multiple programs. eg on over-the-air broadcasts, you might see a channel like 14.1 and 14.2. where 14 is the wireless frequency ID and .1 and .2 are programs in the same MPEG Transport Stream (mpegts)
[14:24:02 CET] <DHE> so the PAT lists the .1 and the .2, and the PMT lists the audio and video streams of each program
[14:24:11 CET] <JEEB> I think this person should just read up on MPEG-TS
[14:24:17 CET] <JEEB> if he wants to do it manually
[14:24:17 CET] <JEEB> or
[14:24:19 CET] <DHE> I think this person should open a .ts file in wireshark
[14:24:19 CET] <JEEB> more honestly
[14:24:35 CET] <JEEB> just use a goddamn demuxing library
[14:24:39 CET] <DHE> I vote ffmpeg
[14:25:09 CET] Action: DHE wrote his own (partial) [de/re]muxer library for mpegts.
[14:27:11 CET] <faLUCE> looking the packets with wireshark I see that 0x0100 indicates a H264 Video pid. So it's a fixed value for H264. Then I could only check that in PES
[14:27:18 CET] <faLUCE> instead of checking PAT and PMTS
[14:27:36 CET] <JEEB> AHAHAHAHAHAHAHAHA
[14:27:41 CET] <JEEB> FIXED PID FOR H.264
[14:27:43 CET] <DHE> wrong
[14:27:51 CET] <DHE> open the PMT (Program Map Table)
[14:27:53 CET] <JEEB> excuse me, but I had to facepalm
[14:28:35 CET] <JEEB> just use a demuxer, m'kay?
[14:29:08 CET] <faLUCE> DHE: opened
[14:30:40 CET] <DHE> start browsing the dissection for it
[14:31:05 CET] <DHE> or just follow JEEB's advice and use software actually designed to deal with this
[14:32:58 CET] <faLUCE> Well, by inspecting the PMT I see that there are two pids, one for the video stream and one for the audio stream. But it's not trivial to obtain the video pid manually.
[14:33:48 CET] <faLUCE> H264 is identified by 0x1b value at the beginning of the PID. So I could get the bytes after that value
[14:34:31 CET] <faLUCE> It should work
[14:35:02 CET] <bencoh> honestly, you really should just use a demuxer
[14:35:18 CET] <bencoh> implementing an mpeg-ts demuxer is not easy
[14:35:29 CET] <faLUCE> bencoh: I don't have to implement a demuxer
[14:35:36 CET] <bencoh> then what do you need?
[14:36:04 CET] <faLUCE> I just have to check if an array, which contains a MPEG PES, indicates a H264 keyframe
[14:37:24 CET] <bencoh> which basically means "I have to know how to find a program with a video/h.264 ES, and check whether, in all those packets, I have the necessary information to decode a (key)frame"
[14:37:58 CET] <faLUCE> I can do that: I check a PMT packet and see if there is the "1b" value on the first streams' PID
[14:38:07 CET] <bencoh> indeed not a demuxer, but still not an easy task, especially if you don't have basic knowledge of how mpeg-ts work
[14:38:09 CET] <DHE> well if that's all you get, you might need an h264 parser
[14:38:10 CET] <bencoh> s
[14:38:32 CET] <faLUCE> then I get the complete PID
[14:39:14 CET] <faLUCE> In fact I wondered if there are parsing function exposed to the user, for this task, in libav
[14:40:15 CET] <DHE> there is a parser API, yes
[14:41:13 CET] <faLUCE> DHE: which header should I see?
[18:02:11 CET] <cool_> hi , i saw this ticket https://trac.ffmpeg.org/ticket/285 i have same problem , when i want to record rtsp udp stream i get missing packges, but on another lib all is fine...
[18:02:31 CET] <cool_> anyone have a sulotion for that?
[19:20:11 CET] <Hel> Hello, how accurate is -ss seeking please ? I'm trying to get a picture overlaying a video, at very precise point, like from frame x to y. But the result always seems a bit random. Despite that, I use miliseconds for the timing.
[19:26:50 CET] <kepstin> the -ss option to ffmpeg should generally give frame-accurate seeking in most formats.
[19:27:27 CET] <kepstin> (with default options, some option combinations will make it less accurate)
[19:31:26 CET] <furq> Hel: the overlay filter supports timeline editing
[19:31:35 CET] <furq> https://ffmpeg.org/ffmpeg-filters.html#Timeline-editing
[19:32:00 CET] <JEEB> libavformat by itself should never be considered frame-exact. ffmpeg.c can be such if you decode, but generally things are not to be trusted
[19:32:12 CET] <JEEB> there are wrappers around FFmpeg that index the file
[19:32:19 CET] <JEEB> and enable frame-exact access
[19:35:44 CET] <Hel> ok, thank you. It must be the way that I try to determine the exact timing of a given frame that is not good. I tried with VLC + extensions and KDEnlive, it didn't worked. Then I tried to extract every frame starting from a givven time with -ss seeking. It didn't worked either. By the way, I also check the results with OpenShot.
[19:39:13 CET] <danieel> are there any rules about how much of audio to prebuffer in a MOV file when doing interleaving ?
[19:39:29 CET] <Hel> this what I do: https://pastebin.com/VxGsREe9
[19:44:08 CET] <Hel> JEEB: did you mean that, 2 different video players may give different timing for the same frame ?
[19:45:09 CET] <JEEB> no, I mean libavformat never really gives you the promise of frame exactness. in the best case it can give you the random access point before that point so you can get to your wanted point by decoding some, but even that can fly right out of the window with a whole crapload of formats
[19:45:27 CET] <JEEB> libavformat being the library in FFmpeg to handle reading and demuxing multimedia formats
[19:46:01 CET] <JEEB> so if you need frame-exactness you use a wrapper on top of libavformat
[19:46:15 CET] <JEEB> which indexes the whole file and lets you access it through that index
[19:46:52 CET] <JEEB> of course, if what ffmpeg.c (the command line application in FFmpeg basing on those base libraries) is good enough for you, it will work. but you've already said that it is not good enough
[19:53:53 CET] <Hel> JEEB oh ok thank for trying to clarify that for me, indeed there is up to 1 sec (30 frames) of gap, which I find not good enough...
[22:18:01 CET] <COOL_> when i save live tream to file (ffmpeg -i http://... static.avi) so it many user see the video i get fast video but when i see the video on browser i see it good.   how can i get the video on static file but on normal ?
[22:18:26 CET] <COOL_> in normal i save the video on 30 fps but when many user watch i get it on 10-15-9 fps
[22:38:18 CET] <COOL_> someone help me? i got disconnected
[22:46:01 CET] <iive> COOL_: sorry, I have no idea about streaming, but stay around somebody might now
[22:46:16 CET] <iive> usually it is not so quite here.
[22:46:53 CET] <COOL_> i not stream, i save live video to file
[22:50:14 CET] <iive> oh, sorry, the I totally did not understood your question.
[22:50:31 CET] <iive> so you are trying to save a stream to a local file.
[22:52:57 CET] <COOL_> iive: yes man
[22:53:27 CET] <iive> is it from youtube?
[22:53:37 CET] <COOL_> no, another site
[23:04:37 CET] <COOL_> iive can you help me about something else?
[23:05:30 CET] <iive> usually you can get different streams from different url's
[23:06:52 CET] <iive> e.g. sometimes the given url contains m3u that is a playlist and have different url's in it, that you can switch.
[23:16:31 CET] <koko> why when i stream rtsp udp i got so bad quality(stack frame or fast speed/slow speed), but when i do it with another lib all is fine ,
[23:17:17 CET] <koko> is ffmpeg has a problem with udp?  when i save rtsp udp stream to static file (i don't want to use c:v copy) i get lot of  package missing and then decode error
[23:17:25 CET] <koko> but another lib(live55) do it well
[23:34:24 CET] <koko> i will be happy to get an answer, i will look on that even i not be here
[00:00:00 CET] --- Mon Nov 20 2017