Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2019

1 participants
62 discussions

ffmpeg.log.20190310
by burek 11 Mar '19

11 Mar '19

[00:03:13 CET] <dkozel> muxrate seems to be what's triggering the problem, I'll have to continue debugging tomorrow. [00:03:34 CET] <dkozel> Any additional tips would be most appreciated. DVB Inspector is definitely quite helpful [00:08:25 CET] <DHE> mpegts is quite the adventure [00:09:42 CET] <DHE> There are some patches against ffmpeg I run on my system [00:56:10 CET] <MotionVector> does anyone know how I can skip a frame in mpeg4videodec.c when using ffplay? if I arbitrarily return "-1" ( < 0) return value for every other VOP_START_CODE found event (I understand it is a hack), it is throwing a "header damaged" in the av_log. [00:56:51 CET] <MotionVector> are there architecture docs available for ffmpeg code? [00:57:39 CET] <JEEB> I think there's some basic docs on how to add new modules into lavf/lavc, and how to utilize the outside visible framework [00:58:40 CET] <JEEB> might help if you explain yer use case [00:59:50 CET] <MotionVector> Hello JEEB, didn't realize you were around :) I am having difficulty with where it can just ignore a VOP and just seek the stream to the next frame. The do_seek works, but it is working at a macro level (i.e., skip 10secs), not at a frame level [01:00:34 CET] <JEEB> yes, seeking only works in time or bytes [01:00:36 CET] <MotionVector> My use case is that I am just trying to skip every other frame to playback at double speed [01:01:27 CET] <MotionVector> the default seems to be 'time' and it converts to bytes anyway based on bit rate [01:01:41 CET] <JEEB> generally that is done by presenting stuff at 2x speed, and you can't skip things on the AVPacket level unless you know that nothing else references the frame you just skipped [01:02:11 CET] <JEEB> and if you know you can skip on AVPacket level then you'd implement your skipping before it even hits the decoder :P [01:03:03 CET] <JEEB> on the other hand, if you need to decode and tehn skip after decoding, seeking is the wrong thing to do anyways [01:03:09 CET] <MotionVector> yes.. exactly. I want to do it as early as possible. but unfortunately, I cannot follow the call tree as it is using the MPEGContext and finding it difficult without the arch doc [01:03:31 CET] <JEEB> you receive all AVFrames from the decoder, and just do nothing with the oens you skip :P [01:03:52 CET] <MotionVector> hmmm.. skip after decoding as in when doing a video_frame_refresh to display? [01:04:11 CET] <JEEB> the decoding API gives you an AVFrame [01:04:20 CET] <JEEB> you throw it to nowhere and be done with it? [01:04:34 CET] <JEEB> it will not lower CPU load for decoding but it will throw half of the decoded pictures away [01:04:51 CET] <JEEB> in case your issue is with rendering the video at 2x rate [01:05:06 CET] <MotionVector> well, it would double the cpu load since I'd decode 2 frames for each VSYNC [01:05:20 CET] <JEEB> you might have already grasped that I'm heavily trying to figure out wtf you're trying to do [01:05:46 CET] <MotionVector> I just want to play it at 2x speed.. [01:06:05 CET] <JEEB> ok, then I wonder how the heck you ended up with trying to do it within the decoder [01:06:06 CET] <MotionVector> play an mpeg4 cideo at 2x or 3x speeds [01:06:12 CET] <MotionVector> ?video [01:07:10 CET] <JEEB> if you are not OK with decoding and know that you can actually completely ignore video packets (no references towards other frames) then you just skip AVPackets and never feed them to the decoder [01:07:27 CET] <MotionVector> I understand the codec (since I wrote mpeg4 back in the day), but have no clue on how ffmpeg works at high level [01:07:40 CET] <JEEB> 1) AVFormat reads AVPackets [01:07:44 CET] <JEEB> 2) AVPacket is fed to decoder [01:07:52 CET] <JEEB> 3) AVFrame is received from decoder if a picture is decoded [01:07:59 CET] <JEEB> 4) API user does something with AVFrame [01:08:13 CET] <JEEB> decoder being in AVCodec [01:08:50 CET] <MotionVector> is AVFrame received in the ffplay.c file? [01:09:01 CET] <JEEB> yes, it's the API client in this case [01:09:10 CET] <JEEB> it uses teh same public APIs as any other API client [01:09:20 CET] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [01:09:30 CET] <JEEB> this is teh thing I generally link regarding the decoding/encoding APIs [01:09:53 CET] <JEEB> but really, there are three ways to do frame skip: [01:10:02 CET] <JEEB> from most "regular" to more specific cases [01:10:24 CET] <JEEB> 1. Just present at 2x speed (most video players have this, no idea if ffplay has since it's closer to a PoC) [01:10:44 CET] <JEEB> 2. Just skip received AVFrames and don't even attempt to render them [01:11:37 CET] <JEEB> 3. In the very specific case where you specifically know that you can ignore some video packets completely, drop AVPackets as they're read from the video stream (this will of course break completely with anything that references those skipped frames) [01:12:02 CET] <MotionVector> option 1. doesn't seem to be present in ffplay (at least, I couldn't find it) [01:12:05 CET] <JEEB> and in all of these cases you will have to speed up the presentation speed (by modifying the received PTS or otherwise) [01:12:23 CET] <MotionVector> Option 3. seems like a good option for not overloading the cpu [01:12:32 CET] <JEEB> but it is also the most limited [01:12:37 CET] <JEEB> because you really need to know your content [01:12:38 CET] <MotionVector> albeit with the risk that oyu highlighted [01:13:17 CET] <MotionVector> I just want to find a way to seek through the stream until next VOP start code [01:13:30 CET] <MotionVector> assuming no p-frames [01:13:31 CET] <MotionVector> or b [01:13:53 CET] <JEEB> you mean a random access point? [01:14:50 CET] <JEEB> and you wanted to speed up playback and unless you specifically only receive content that has a GOP of 2 frames, you ain't going to get 2x speed with AVPacket frame skip :P [01:15:06 CET] <MotionVector> not random really, to the next every other frame (I transcoded the video to be all i-frames) so there should be no interframe prediction dependency [01:15:38 CET] <MotionVector> my gop is 1 frame [01:15:40 CET] <MotionVector> :D [01:16:43 CET] <JEEB> ok, then you can do something like "skip as many frames as per your thing, and then look for the next AVPacket with the keyframe flag" [01:16:54 CET] <JEEB> and random access point aka RAP is normal MPEG lingo [01:17:03 CET] <MotionVector> ok [01:17:16 CET] <JEEB> it means a point from which you can start decoding so that the following pictures do not require references on the other side of it [01:17:22 CET] <MotionVector> where do i start looking for this? any file name to start? [01:17:27 CET] <JEEB> your API client [01:17:35 CET] <JEEB> if you are poking at ffplay.c then that is it [01:18:07 CET] <JEEB> I hate how it's named, but av_read_frame() is the thing that reads the following AVPacket [01:18:46 CET] <MotionVector> cool.. you are my guiding star JEEB. Thank you! [01:19:00 CET] <JEEB> if you do not get a negative value from that (errors are negative) you have a new AVPacket from that function [01:19:20 CET] <JEEB> AVPacket has pts/dts fields [01:19:24 CET] <JEEB> as well as duration I think [01:21:16 CET] <MotionVector> yeah, I started with the pts/dts and duration stuff and was lost a bit so I started digging into the codec (the place I know what's happening) [01:21:42 CET] <JEEB> ffplay seemed to have some speed related stuff but E_NO_IDEA [01:21:47 CET] <MotionVector> I come from more the DSP algorithms world so even the file containers are kind of foreign to me [01:21:59 CET] <ricemuffinball> 10 hours to encode a 1 hour HD video. is this normal [01:22:08 CET] <JEEB> I hack other players myself although surprisingly many people utilize ffplay [01:22:25 CET] <MotionVector> ffplay seems convenient :) [01:23:08 CET] <ricemuffinball> 10 hours to encode a 1 hour HD video. is this normal: how does youtube does it so fast? [01:24:04 CET] <JEEB> youtube uses fast settings (they don't care about quality until normal people start quitting the service), and they have over 9000 servers to split the job across (they encode in parts) [01:24:19 CET] <JEEB> and yes, there is no limit to how long you can encode a piece of video [01:24:35 CET] <JEEB> that question is utterly and completely useless without any additional info [01:25:23 CET] <ricemuffinball> so if i upload a highquality video to youtube, does it result in poor quality in youtube? [01:25:41 CET] <JEEB> yes. how poor depends on how needing your source is. [01:25:47 CET] <JEEB> how complex and/or hard to encode it is [01:26:01 CET] <JEEB> they will first filter it somewhat to get small detail and/or input artifacts out [01:26:04 CET] <JEEB> then encode [01:26:14 CET] <ricemuffinball> what if i want to upload a video to youtube demonstrating this new technology camera, and how good the video quality is [01:26:20 CET] <MotionVector> Thank you, JEEB~ I'll let you know if I succeed at my experiment [01:26:33 CET] <JEEB> ricemuffinball: then you're fucked. youtube is not a service for high quality video. it never was. [01:26:42 CET] <JEEB> you do it elsewhere [01:26:58 CET] <JEEB> most camera manufacturers host their own videos [01:26:59 CET] <ricemuffinball> fair enough [01:27:11 CET] <JEEB> straight off of the video output of the camera [01:27:33 CET] <JEEB> of course, many also put the stuff onto youtube but in that case they usually want to show pretty pictures [01:27:38 CET] <JEEB> nice cinematography etc [01:27:44 CET] <JEEB> not the compression quality [01:31:21 CET] <ricemuffinball> but can you tell the difference between fast encoding and superslow encoding: if CRF is same [01:32:13 CET] <JEEB> same CRF is not same quality nor same file size. but you can achieve the same quality with both slower and faster presets - you just need to use more bits with faster presets [01:32:17 CET] <ricemuffinball> assuming you know what crf is [01:32:34 CET] <JEEB> (and the first sentence is mostly regarding CRF and presets) [01:32:46 CET] <JEEB> (because presets' internals decide what CRF sees and cannot see in a way) [01:33:01 CET] <JEEB> (thus the internals of what a certain CRF value means are different from each preset) [01:33:30 CET] <JEEB> but hte main part was the second sentence, that with any sane encoder you can get the same quality with faster presets as well [01:33:38 CET] <JEEB> you just have to use more bits because you're using less time [01:33:42 CET] <JEEB> (to encode) [01:34:08 CET] <JEEB> also, your problem with encoding speed is not always encoding - make sure you don't have bottlenecks in your decoding or filtering :P [01:34:55 CET] <JEEB> and the whole speed thing is why I always with x264 recommend people to first pick the preset that is the slowest "this is OK for me" for them with a test clip [01:35:00 CET] <JEEB> (like 2600 frames or so) [01:35:11 CET] <JEEB> then after they have picked the speed, you adjust CRF [01:35:19 CET] <JEEB> for your required quality level [01:35:48 CET] <JEEB> same rules do apply to x265, although the internals of x265 are quite different as the two projects do not share a code lineage [01:42:10 CET] <ricemuffinball> but is CRF level of x264 and x265 about the same [01:42:20 CET] <JEEB> no [01:42:29 CET] <ricemuffinball> huh? it's not [01:42:37 CET] <JEEB> they have their own ranges, [01:42:56 CET] <JEEB> you can see it from the defaults, too :P x264 starts at 23, x265 starts at 28 [01:43:16 CET] <iive> is x265 using similar qp ? [01:43:39 CET] <JEEB> no idea, but what the CRF values actually mean is different enough [01:43:51 CET] <JEEB> the code base is different so you wouldn't expect something like CRF to be the same [01:53:16 CET] <ricemuffinball> is it normal that 2k VIDEO has 60fps or 50fps [01:54:34 CET] <JEEB> both 50Hz and 60(/1.001)Hz are completely normal rates and while not often utilized in movies, I don't see any weirdness in those rates [01:54:53 CET] <JEEB> you are asking such vague questions that they can only be responded in vagueness [01:56:03 CET] <ricemuffinball> not understanding why there are 60/50 fps in the first place: regardless if the resolution is 4k/2k or not [01:57:18 CET] <ricemuffinball> would 4k video with 30fps look bad or something ? [01:57:26 CET] <JEEB> broadcast rates were that for analog video in NTSC/PAL regions. that then translated into screen refresh rates etc. I really don't see anything weird in them [01:57:42 CET] <JEEB> those rates are still common for screen capture or higher rate cameras [01:57:56 CET] <JEEB> umm, frame rate is really separate from resolution [01:58:26 CET] <JEEB> the more frames in theory the smoother the motion. that said, it all depends on the content [01:58:29 CET] <ricemuffinball> JEEB exactly but you don't see 60 fps Standard resolution video [01:58:34 CET] <JEEB> why not? [01:58:38 CET] <ricemuffinball> you just don't [01:58:50 CET] <JEEB> right, all those things I've seen were a lie then. a great lie [01:59:42 CET] <JEEB> out of the most common stuff: [01:59:47 CET] <JEEB> 1. field rate deinterlaced content [01:59:50 CET] <JEEB> 2. screen captures [01:59:56 CET] <JEEB> 3. 60Hz camera captures in SD [02:02:42 CET] <ricemuffinball> is 23.97 still relavant fps [02:03:30 CET] <another> soo much lieing! SAD! [02:04:25 CET] <JEEB> most end user movie content is either 24/1.001 (~23.97) or 24 [02:04:42 CET] <JEEB> and SD stuff often 25 because that was more usual on DVDs [02:04:55 CET] <JEEB> on blu-rays people stopped doing the standards conversion in most cases [02:05:17 CET] <JEEB> there are some european movies that were shot in 25 which then are released like that of course [02:05:23 CET] <JEEB> (more often TV series, though) [02:07:17 CET] <ricemuffinball> is it true that theatre in europe finishes quicker than northamerica : on exact same movie [02:07:35 CET] <ricemuffinball> i heard somebody saying that, but that makes no sense [02:08:00 CET] <iive> theatre no [02:08:07 CET] <iive> but on TV sometimes [02:08:17 CET] <ricemuffinball> that still makes no sense [02:08:27 CET] <ricemuffinball> time should exactly same [02:08:30 CET] <ricemuffinball> time should be exactly same [02:08:34 CET] <another> well no [02:08:34 CET] <iive> Pal is 25 frames, movie is 24 frames. [02:09:11 CET] <ricemuffinball> it just means human eyes has seen less frames during the course of the show/movie [02:09:12 CET] <iive> if you broadcast 24 frame movie on PAL, you need to repeat 1 frame every second, and it could be felt. [02:09:23 CET] <iive> as choppiness. [02:09:57 CET] <iive> so you speed it up 25/24 times and you have perfect match. [02:10:32 CET] <ricemuffinball> so theater in europe still use 23.97 [02:10:44 CET] <JEEB> no, theatres are 24 [02:10:59 CET] <JEEB> 24/1.001 is for broadcast-based or end user electronic stuff [02:11:08 CET] <ricemuffinball> so all theatres are 24 regardless youare in europe or NA? [02:11:14 CET] <iive> because NTSC is 30/1.001 [02:11:18 CET] <JEEB> well not limited to that most likely [02:11:42 CET] <JEEB> most likely theatres can do faster refresh rates, but 24Hz is the classic [02:11:57 CET] <ricemuffinball> why is theatre still using 24 [02:12:04 CET] <JEEB> because that's what people are used to [02:12:14 CET] <iive> because it looks choppy [02:12:27 CET] <ricemuffinball> iive and that's a good thing? [02:12:35 CET] <JEEB> that's what people are used to [02:12:35 CET] <iive> e.g. The Hobit was filmed at 48fps [02:12:56 CET] <ricemuffinball> why 48 and not 60? [02:13:02 CET] <JEEB> ask the author [02:13:07 CET] <JEEB> but probably because 2x 24 [02:13:29 CET] <iive> People perceive smooth motion as TV series, thus cheap. Monty Pyton even had a sketch about it. [02:13:42 CET] <ricemuffinball> is there a move that is filmed not divisible by 24 ? [02:13:53 CET] <JEEB> most likely yes, somewhere in the world [02:13:54 CET] <iive> IMAX movies [02:14:02 CET] <JEEB> I mean old movies were 12 or whatever frames per second? [02:14:08 CET] <iive> no [02:14:15 CET] <JEEB> the ones that were clearly not 24 [02:14:17 CET] <iive> 24 is literally the minimum. [02:14:17 CET] <ricemuffinball> i meant recent years [02:14:48 CET] <iive> some children animation may be produced at lower rates [02:15:08 CET] <iive> because of the labor needed for each frame. [02:15:11 CET] <JEEB> umm, I'm pretty sure I remember things where things are sped up [02:15:13 CET] <pink_mist> lots of anime have parts that are as low as 4fps [02:15:17 CET] <JEEB> from 1910 to 1940s [02:15:26 CET] <JEEB> which I assume that the sped up stuff is 24 [02:15:35 CET] <JEEB> and thus the original capture rate was slower than 24 [02:15:43 CET] <ricemuffinball> if imax produce a movie with FPS that is not divide by 24 then, how does theater show it [02:16:04 CET] <iive> they have special projectors and special screens [02:16:29 CET] <another> silent film used ~16fps [02:16:43 CET] <JEEB> https://en.wikipedia.org/wiki/Frame_rate#Film_and_video [02:16:49 CET] <JEEB> so yes [02:17:03 CET] <ricemuffinball> then how comes movies still continues to use 23.97 if theaters have special projectors [02:17:32 CET] <JEEB> because it has become the standard, and because you have to take the rate into account when creating content [02:18:07 CET] <iive> imax is not standard [02:18:27 CET] <iive> but with the move to digital cinema, higher framerates would become common. [02:18:35 CET] <ricemuffinball> but Highresolution was not a standard at one point too [02:18:59 CET] <JEEB> you have to f.ex. control the focus of a person much more with higher rate film content because with shorter capture lengths you tend to get a much less blurry image [02:19:17 CET] <JEEB> and when oyu have more not blurry stuff on screen that is much more random detial around [02:19:43 CET] <JEEB> that IIRC was one of the problems I feel like the hobbit had (other than bundling higher frame rate with multiview) [02:20:23 CET] <JEEB> for multiview you need less blurry images and they kept that, while not taking into account that people would lose their focus more easily if there was a lot of crap on screen :P [02:20:26 CET] <ricemuffinball> and how come you see movies with bluray/HD that was shot like 50 years ago [02:20:47 CET] <ricemuffinball> when nobody has even heard of HD [02:21:08 CET] <iive> movies are shot of film, and it has resolution about a molecule. [02:21:25 CET] <iive> aka, they are analog. [02:21:37 CET] <iive> and a lot of sharpen filters :) [02:22:54 CET] <iive> that's why the prequels of SW are not likely to get UHD, since they were shot at 2K. [02:23:21 CET] <iive> with digital cameras. [02:23:29 CET] <furq> 8mm film is normally 18fps [02:23:32 CET] <furq> and super8 etc [02:24:13 CET] <ricemuffinball> 2k doesn't count as UHD? [02:24:18 CET] <furq> and obviously anything from when cameras were hand-cranked is going to be all over the place [02:25:17 CET] <ricemuffinball> do you think we will reach a resolution so high that "okay this is good enough" : let's stop ? [02:26:05 CET] <ricemuffinball> or is it going to neverending cycle 4k 8k 16k 32k ? [02:27:13 CET] <ricemuffinball> audio has been stuck @ 192khz for a while now [02:27:39 CET] <ricemuffinball> never seen higher than 192khz audio [02:27:45 CET] <furq> i've seen 384k audio [02:27:51 CET] <furq> it's exactly as pointless as 192k and 96k are [02:28:09 CET] <ricemuffinball> 384 khz wow [02:28:22 CET] <ricemuffinball> do you think we will reach a VIDEO resolution so high that "okay this is good enough" : let's stop ? [02:29:07 CET] <ricemuffinball> furq 96K is not pointless [02:32:10 CET] <another> depends [02:32:29 CET] <ricemuffinball> another which question? [02:32:33 CET] <another> i think 4k or 8k is already the limit [02:32:47 CET] <another> 96k _can_ be usefull [02:33:01 CET] <ricemuffinball> 4k/8k has not been standardlized yet though [02:33:18 CET] <another> ? it hasn't? [02:33:38 CET] <another> afaik .jp is already broadcasting 8k [02:33:52 CET] <ricemuffinball> another i am talking about after most majority of people have 4k/8k TV/monitor [02:35:41 CET] <ricemuffinball> i am talking about when there is a point where "if everybody who has HDTV now, they all have 4k TV isntead" [02:36:20 CET] <another> alright [02:36:44 CET] <another> the trend goes more towards more color, hdr, etc [02:36:48 CET] <ricemuffinball> okay we want 16K now [02:36:50 CET] <another> instead of higher res [02:37:35 CET] <another> because at common tv screen sizes you simply can't distinguish the pixels anymore [02:37:45 CET] <another> (from a resonable distance) [02:38:15 CET] <mozzarella> depending on the size of the display [02:38:31 CET] <another> sure [02:39:16 CET] <ricemuffinball> another so even in Year 2200 you don't think people will be using higher than 8K TV [02:39:21 CET] <another> but i think there's a limit of tv size [02:40:03 CET] <another> i'm not gonna make predictions that far into the future [02:40:35 CET] <another> some companies will probably sell 16k, 32k screens [02:40:45 CET] <another> because BIGGER NUMBERS [02:41:21 CET] <ricemuffinball> another so basically that means "no" to my original question: do you think we will reach a VIDEO resolution so high that "okay this is good enough, let's stop now" [02:43:42 CET] <another> well, rationally i think we already reached that point for consumers [02:44:08 CET] <another> however, marketing and people are not always rational [02:44:58 CET] <ricemuffinball> another "reached the point" on which resolution ? [02:45:04 CET] <another> i mean in audio there are 24bit/192khz flac downloads for sale [02:45:09 CET] <another> 4k [02:45:51 CET] <another> reg. audio: does it make sense? no. will people buy it? yes. [02:46:01 CET] <ricemuffinball> another is that mean you think 8k is useless? : you did say earlier: <another> afaik .jp is already broadcasting 8k [02:46:05 CET] <another> if people are willing to buy it, someone will sell it [02:47:39 CET] <another> for consumption? yes [02:48:49 CET] <another> but that's just my 2 cents [02:51:29 CET] <ricemuffinball> is there even a CPU that can decode 8K video realtime [02:53:19 CET] <dongs> yes like all of them [02:54:07 CET] <ricemuffinball> huh [03:11:57 CET] <CyberShadow> How long do the trac verification emails usually take to arrive? [03:16:38 CET] <relaxed> CyberShadow: #awhile [03:17:42 CET] <CyberShadow> What's the order of magnitude? Days, weeks? [03:18:37 CET] <relaxed> probably a day or few days [03:19:01 CET] <CyberShadow> You're kidding. Do they need to be manually approved or something? [03:19:20 CET] <CyberShadow> Does it go through RFC 1149? [03:21:45 CET] <relaxed> I'm not sure about the exact process, but it may be manual [03:24:22 CET] <relaxed> what's your issue? [03:26:27 CET] <CyberShadow> I have a patch for an issue that could use some testers [03:33:51 CET] <relaxed> great, please be patient- I'm sure it will be reviewed soon [03:38:10 CET] <relaxed> CyberShadow: If it's not in a day or two, inquire about it in #ffmpeg-devel [03:38:21 CET] <CyberShadow> OK, thanks [04:17:52 CET] <ossifrage> I am completely failing to get libavformat to mux a h264 elementary stream [04:21:25 CET] <ossifrage> Doing encoding with ffmpeg was fairly low pain (and there are plenty of good examples), but multiplexing is giving me pains [07:23:09 CET] <antigravity83> Hi everyone, hoping to get some help with remuxing AVI to MP4. New file has lower framerate on playback, despite using copy command [10:40:23 CET] <ongo> Does ffmpeg support a selection to screen capture? (Something like maim) [11:36:24 CET] <DHE> clicking to select a range? no. you have to specify your own coordinates numerically [11:39:26 CET] <BtbN> CyberShadow, patches go to the ML anyway, not to trac. And the E-Mails from trac are supposed to arrive instantly. If they don't, check your spam folder. [11:40:45 CET] <CyberShadow> BtbN: My patch is not yet ready for inclusion, I am looking for testers for feedback first. It's not in my spam folder. [11:41:01 CET] <BtbN> That's fine, RFC patches are not uncommon. [11:42:42 CET] <CyberShadow> Maybe I should be more specific. The issue in question is http://trac.ffmpeg.org/ticket/2104 . I am looking for users suffering from photosensitive epilepsy, I expected to have better reach on that issue than in the ML in general [11:43:38 CET] <BtbN> Well, depends on what kind of feedback you want. Code Review is definitely better done on the ML. [11:43:40 CET] <CyberShadow> Thanks for the suggestion [11:44:01 CET] <BtbN> But really, registration is supposed to be instant. There is no manual process involved. [11:44:08 CET] <CyberShadow> No, I'm looking for feedback on how effective the algorithm is. I'll work on code quality after that. [11:44:48 CET] <CyberShadow> Okay. Trac is not letting me do anything until I verify my email address, but no message arrived so far. [11:45:11 CET] <CyberShadow> I guess I could try a different address. [11:45:26 CET] <BtbN> Is it Hotmail/live/anything Microsoft? [11:45:56 CET] <CyberShadow> No, it's my domain, redirecting to Gmail. Usually there's no issue with dropped messages. [11:46:39 CET] <CyberShadow> It doesn't look like my email server (redirecting) received anything at the address I registered on Trac with. [11:47:06 CET] <CyberShadow> Using plain Gmail worked. [11:54:59 CET] <DHE> gmail's antispam behaviour has been getting pretty vicious lately, bouncing messages it doesn't like at the SMTP layer [11:57:08 CET] <DHE> reminds me, I have some patches I'd like to submit as well.. [12:00:36 CET] <CyberShadow> DHE: I've been seeing that since a while ago, but so far it was mostly for extreme cases (blatant spam/malware or some runaway cronjobs). [12:01:27 CET] <CyberShadow> And, I've been having problems with Microsoft as well - for some reason they blocked the IP range, and there was no clear process for getting it unblocked. [12:23:08 CET] <damdai> The AV1 bitstream specification includes a reference video codec. It succeeds VP9. It can have 20% higher data compression than VP9 or HEVC/H.265 from the Moving Picture Experts Group and about 50% higher than the widely used AVC [12:23:31 CET] <damdai> is this true? av1 destroys avc ? [12:25:40 CET] <JEEB> damdai: when we get encoders that do that with all use cases, yes [12:25:52 CET] <JEEB> as with HEVC, a format is only as good as its encoders [12:25:58 CET] <damdai> huh, didn't understand you [12:26:11 CET] <damdai> can you rephrase please [12:26:38 CET] <JEEB> "when we get encoders that do that <destroy another format> with all use cases, yes" [12:26:39 CET] <BtbN> CyberShadow, I'm unable to send E-Mails to Microsoft for ages. They blocked my servers IP, and when I asked to be unblocked they told me to "Build more reputation of not sending spam." [12:26:44 CET] <BtbN> with no further comment on how [12:27:01 CET] <CyberShadow> Yeah that sucks [12:27:28 CET] <JEEB> damdai: the really low bit rate use cases (where things generally look really bad in both formats most likely) it's simpler to beat an older format [12:27:32 CET] <damdai> jeeb are you trying to say "av1 has a lot of potential but there aren't any good encoders NOW as of this moment? [12:27:33 CET] <JEEB> but then you go up from that [12:27:39 CET] <JEEB> damdai: aye [12:27:57 CET] <JEEB> same as HEVC. I'm still not sure about the encoders for it for higher bit rate scenarios (basically, detail retention) [12:28:03 CET] <BtbN> Encoding AV1 in real time just isn't a thing at the moment, and decoding fully utilizes your normal desktop PC in the best case [12:28:05 CET] <JEEB> although I last tested in 2017 :P [12:28:21 CET] <JEEB> BtbN: dav1d is making the decoding a lot less of an issue [12:28:41 CET] <BtbN> h264 will be around for a while I guess, as it's in the sweet spot of required performance and quality [12:28:45 CET] <JEEB> yes [12:28:49 CET] <BtbN> and software availability [12:28:52 CET] <damdai> jeeb good encoders exist or not, youtube uses av1 [12:29:00 CET] <JEEB> yes, youtube will take the PR points [12:29:08 CET] <damdai> PR? [12:29:10 CET] <BtbN> YouTube only uses av1 for low resolutions and bitrates [12:29:12 CET] <JEEB> public relations [12:29:22 CET] <BtbN> not for anything high res, as nobody would be able to decode it [12:29:29 CET] <JEEB> like, youtube has never been the den of high quality [12:29:50 CET] <BtbN> But at low bitrates and resolutions, they might be able to improve the quality a bit compared to h264/vp9 [12:30:00 CET] <JEEB> you can probably find a quote of me explaining the seeming requirements of youtube somewhere on this channel's log :P [12:30:08 CET] <DHE> yes, AV1 is basically 2 generations ahead of H.264 [12:30:26 CET] <JEEB> (keep quality so that your usual people don't quit, and shave bandwidth [12:30:31 CET] <DHE> I tried a test encode of 1080p25 content to AV1 at 1 megabit. it is very watchable. (other than the CPU stuttering to keep up with decoding) [12:30:47 CET] <JEEB> although I think when they added VP9 tehy actually used more bandwidth [12:30:53 CET] <JEEB> (compared to AVC) [12:30:59 CET] <JEEB> (For the same res/frame rate) [12:31:25 CET] <JEEB> and yes, for the low bit rate game beating old encoders is much more doable [12:31:54 CET] <JEEB> and it's a very valid requirement [12:31:58 CET] <JEEB> and/or use case [12:32:13 CET] <DHE> looking at a random-ish video on youtube, vp9 is 2.3 megabits but h264 is 3.2 megabits at the same resolution [12:32:23 CET] <damdai> 397 mp4 640x480 480p 540k , av01.0.05M.08, 30fps, video only, 155.20MiB [12:32:23 CET] <damdai> 244 webm 640x480 480p 583k , vp9, 30fps, video only, 168.56MiB [12:32:23 CET] <damdai> 135 mp4 640x480 480p 888k , avc1.4d401e, 30fps, video only, 211.67MiB [12:32:25 CET] <JEEB> DHE: yea, that might have changed afterwards :) [12:32:37 CET] <DHE> oh yeah, google will play with this stuff all the time [12:32:53 CET] <DHE> I'm also looking at the 1080p feeds [12:33:14 CET] <DHE> wait, is format 397 av1 ? [12:33:18 CET] <damdai> av1 is 540k when avc is 888k [12:33:24 CET] <damdai> DHE yes [12:33:35 CET] <JEEB> bit rates say nothing about quality for the record [12:33:43 CET] <JEEB> but at least they're using it at a lower bit rate :P [12:33:53 CET] <JEEB> so they're supposedly at least saving something when pushing that out [12:34:21 CET] <damdai> does mp4 not support vp9 ? [12:34:36 CET] <JEEB> I /think/ there is a mapping for it [12:34:42 CET] <JEEB> but youtube started using vp9 with webm [12:34:52 CET] <JEEB> so their thing probably works with that [12:35:29 CET] <JEEB> https://mp4ra.org/#/codecs [12:35:36 CET] <JEEB> yea they registered vp8/9 [12:35:42 CET] <dongs> speaking of codecs [12:35:57 CET] <dongs> im not dismissing the possibility that this hevc shit is too high level to be properly decoded by ffmpeg/vlc/mpc-hc [12:36:07 CET] <dongs> is tehre a reference hevc decoder thats super slow that can just output a png or something of each frame [12:36:14 CET] <dongs> that supports HDR and all that other weird shit [12:36:37 CET] <JEEB> for HDR playback you might check out mpv [12:36:39 CET] <dongs> cuz even from ffmpeg i get warnings about hevc sps/pps /etc shit [12:36:41 CET] <JEEB> that has nice tone mapping [12:36:42 CET] <JEEB> ah [12:36:46 CET] <JEEB> only in the beginning [12:36:47 CET] <dongs> no, i dont carea bout acutal palyback [12:36:48 CET] <JEEB> ? [12:36:53 CET] <dongs> i want ot make sure the frame isnt actualyl garbage [12:36:56 CET] <JEEB> ok [12:36:59 CET] <damdai> jeeb is that mean first version of x264 also sucked ? [12:37:03 CET] <JEEB> HM is the reference [12:37:05 CET] <JEEB> damdai: yes [12:37:10 CET] <JEEB> although the fight was simpler back then [12:37:10 CET] <dongs> wheer is that [12:37:12 CET] <JEEB> just with CABAC [12:37:19 CET] <JEEB> because mpeg-4 part 2 was crap [12:37:27 CET] <JEEB> (and h.263 was only a bit better) [12:37:43 CET] <damdai> i wish i can compare first version of x264 and latest version of x264 [12:37:47 CET] <JEEB> dongs: https://hevc.hhi.fraunhofer.de/ [12:37:56 CET] <JEEB> damdai: also there was a lot more psychovisual optimizations done [12:38:01 CET] <JEEB> plus all the SIMD [12:38:07 CET] <JEEB> and the CPUs became faster [12:38:10 CET] <dongs> i have ot *build* this shit? [12:38:13 CET] <JEEB> yes [12:38:20 CET] <esspapier> kek [12:38:23 CET] <dongs> ffs [12:38:24 CET] <JEEB> it has an MSVS project tho [12:38:25 CET] <JEEB> IIRC [12:38:27 CET] <JEEB> if you like that [12:38:29 CET] <dongs> ok [12:38:34 CET] <dongs> thats good [12:38:45 CET] <dongs> > still using svn in 2019 [12:38:48 CET] <JEEB> yes [12:38:58 CET] <JEEB> they started in like 2010 or so, and even then it was lulz [12:38:59 CET] <damdai> JEEB would you able to tell the difference between very first version of x264 encoded video vs latest version of x264 encoded video using same CRF 20 [12:39:08 CET] <esspapier> company I work for uses svn and I hate it every day [12:39:09 CET] <JEEB> same CRF is not same bit rate nor quality [12:39:20 CET] <esspapier> they fear to merge whenever it comes up [12:39:40 CET] <JEEB> esspapier: reminds me of the mpc-hc history. there's a lolhueg commit called "merge beliyaal's branch" [12:39:41 CET] <dongs> > implying git makes merging any easier [12:39:48 CET] <JEEB> dongs: at least it keeps histories [12:40:06 CET] <JEEB> now in mpc-hc's code you no longer have an idea wtf beliyaal's branch was and why it had some changes [12:40:18 CET] <JEEB> it's a cherry-pick/checkout of the whole thing's current state as-is [12:40:21 CET] <damdai> is it possible to get ffmpeg with old/first version of x264 [12:40:27 CET] <JEEB> probably not [12:40:32 CET] <damdai> why not [12:40:38 CET] <JEEB> the API changed [12:40:45 CET] <dongs> i dont even have subersion installed ont his shit [12:40:46 CET] <JEEB> and/or wasn't there in the beginnig [12:40:47 CET] <dongs> what the hehll [12:40:58 CET] <JEEB> so testing with the x264 cli probably is a better idea :P [12:41:08 CET] <JEEB> I think someone actually did tests at the same bit rate [12:41:16 CET] <JEEB> with somewhat similar (?) params [12:41:19 CET] <JEEB> on ye olde doom9 [12:41:25 CET] <damdai> jeeb link? [12:41:26 CET] <JEEB> like a revision from each year or whatever [12:41:32 CET] <dongs> so after building this , is this just gonna be like a hm.exe test.hevc out.png or something or other? [12:41:53 CET] <JEEB> dongs: it dumps raw YCbCr into a single file [12:42:08 CET] <JEEB> anyways if you have a raw annex b stream I could take a look at it if you want :P [12:42:31 CET] <dongs> lemem see if I can remove some debugging shit and dump some [12:42:52 CET] <damdai> what avc encoder does youtube use? [12:42:56 CET] <JEEB> although I'd probably just run the dump headers bit stream filter on its first XYZ bytes to see if you have the parameter sets alive [12:43:07 CET] <JEEB> damdai: take a wild guess [12:43:20 CET] <JEEB> take also a wild guess which decoders for things they use [12:43:46 CET] <damdai> i would have guessed x264 but their video doesn't have the x264 meta data [12:43:59 CET] <JEEB> are you implying that's hard to remove :P [12:44:05 CET] <JEEB> (it's a single SEI message) [12:44:20 CET] <damdai> why would they bother removing it [12:44:24 CET] <dongs> uhh [12:44:26 CET] <damdai> unless they are ashamed of it [12:44:29 CET] <dongs> i think this svn shit is pulling out entire fucking history of HM [12:44:32 CET] <dongs> isntead of just top branch [12:44:40 CET] <JEEB> ouch [12:44:55 CET] <JEEB> I'm just happy I never had to deal with HM past 2012 [12:45:06 CET] <JEEB> that shit was slow [12:45:11 CET] <fling> What is HM? [12:45:15 CET] <dongs> https://mega.nz/#!5cVVEY6D!saiExKHeZeg3dZHsMtUXU9fchkNRH1Z8YSon1n8C74E [12:45:18 CET] <dongs> ^ JEEB [12:45:18 CET] <JEEB> reference HEVC enc/dec [12:45:23 CET] <JEEB> dongs: thanks, will grab [12:45:30 CET] <dongs> 2.3gb of sores [12:45:40 CET] <dongs> hevc is like 50megs, just first few seconds [12:45:47 CET] <damdai> youtube video deosn't have this meta data: x264 core 148 [12:45:47 CET] <damdai> Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=22 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 [12:45:47 CET] <damdai> / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=abr / mbtree=1 / bitrate=4800 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00 [12:45:56 CET] <fling> Can't I set input bitrate for v4l2? [12:46:04 CET] <JEEB> damdai: yes that's in the SEI message [12:46:17 CET] <JEEB> they probably strip it to remove hints of what settings they use [12:46:30 CET] <damdai> i would like to see that meta data [12:46:48 CET] <JEEB> dongs: oh fucking wow [12:46:52 CET] <JEEB> they are using HLG?! [12:47:00 CET] <dongs> http://bcas.tv/paste/results/U1J1zp43.html [12:47:02 CET] <dongs> yes [12:47:02 CET] <fling> What is HLG? [12:47:04 CET] <damdai> jeeb does youtube use ffmpeg for decoding? [12:47:12 CET] <JEEB> fling: alternative to PQ [12:47:15 CET] <JEEB> as a transfer function [12:47:22 CET] <JEEB> PQ = Dolby , HLG = NHK/BBC [12:47:32 CET] <fling> I need to read about this& [12:48:11 CET] <JEEB> dongs: yea it seems like you have some metadata there, but then something's missing and/or borked. [12:48:17 CET] <JEEB> I'm still checking [12:48:21 CET] <dongs> right [12:48:54 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#trace_005fheaders [12:48:57 CET] <JEEB> this is the bit stream filter btw [12:49:14 CET] <damdai> what has more potential? vp9 or h265 [12:49:45 CET] <dongs> uhh how do i use that ffmpeg -i shit.hevc -f trace_headers -c copy ? [12:50:03 CET] <damdai> .hevc ? [12:50:03 CET] <dongs> damdai: in my personal opinion, all VP* stuff is dead/nonstarter [12:50:10 CET] <BtbN> You can't use filters and -c copy at the same time. [12:50:14 CET] <dongs> patent issues with h265/etc aside, as long as nobody actually uses teh codec, it remains dead [12:50:14 CET] <JEEB> ffmpeg -v verbose -i PID-A001-MPU.hevc -bsf:v trace_headers -c copy -f null - [12:50:22 CET] <JEEB> this is what I just did [12:50:24 CET] <damdai> dongs what do you mean by "dead/nonstarter" [12:50:43 CET] <JEEB> and then redirect stderr into logs.log [12:50:44 CET] <BtbN> HEVC died the moment it had more than one patent pool opening their hands [12:50:44 CET] <JEEB> or something [12:50:55 CET] <dongs> BtbN: and VP9 was never alive [12:51:16 CET] <damdai> btbN HEVC died? [12:51:37 CET] <damdai> what are you people talking about dying/dead ? [12:51:39 CET] <BtbN> No Browser supports it, so usage is minimal. [12:52:09 CET] <JEEB> dongs: ok, I see VPS, SPS, PPS all there [12:52:15 CET] <JEEB> all for ID zero as far as I can tlel [12:52:17 CET] <damdai> how can browser support vp9 but not h265 [12:52:27 CET] <dongs> if you try to play it back just as raw .hevc in say mpc-hc there's distortion/crap [12:52:28 CET] <BtbN> Because they don't want to get sued over patents. [12:52:31 CET] <dongs> caused by no idea what tho [12:52:48 CET] <YamashitaRen> Only warez has a wide use for x265. [12:52:51 CET] <JEEB> yes, something's definitely wrong [12:52:55 CET] <YamashitaRen> That tells you how mainstream it is. [12:53:03 CET] <damdai> btbn why aren't they afraid of getting sued for support vp9/avc then? [12:53:13 CET] <damdai> supporting* [12:53:20 CET] <JEEB> dongs: seems to be data corruption because the POCs it's looking for have really weird IDs [12:53:54 CET] <BtbN> Because there are no patents for VP9, and h264 has a proper patent pool that puts no charges on people making players, only people distributing/encoding video. [12:53:56 CET] <JEEB> and I'm using an ASIC to decode as well so it's not FFmpeg's decoder [12:54:22 CET] <BtbN> The 3 patent pools behind HEVC want royalties for even thinking about the codec. [12:54:53 CET] <damdai> btbn i see [12:55:32 CET] <JEEB> also AUDs in the stream, nice [12:55:32 CET] <dongs> jeeb what's POC? (in this context [12:55:45 CET] <dongs> nvm found [12:55:46 CET] <JEEB> dongs: basically an ID the decoder tries to reference things against [12:55:47 CET] <damdai> btbn what other video/audio codec does not have "proper patent pool that puts no charge on making players" [12:56:00 CET] <JEEB> so it's lacking a reference with that ID [12:56:05 CET] <dongs> hmm [12:56:07 CET] <BtbN> what? [12:56:09 CET] <dongs> we do have timestamps [12:56:11 CET] <dongs> in a separate PID [12:56:19 CET] <dongs> they're quite complex and referenced to NTP/wahtever [12:56:20 CET] <dongs> but they are there [12:56:26 CET] <JEEB> so either things are out of order, or there's corruption [12:56:32 CET] <dongs> but I wouldn't think timestamps would be requierd to just do dumb decode eh? [12:56:35 CET] <JEEB> I'm trying to go through the trace_headers dump [12:56:35 CET] <dongs> hmm [12:56:40 CET] <JEEB> no, timestamps wouldn't be [12:56:44 CET] <JEEB> just NAL units in order [12:57:02 CET] <damdai> why isn't ffmpeg afraid of getting sued by HEVC ? [12:57:13 CET] <JEEB> FFmpeg only provides sauces [12:57:17 CET] <damdai> why isn't ffmpeg afraid of getting sued by HEVC then? since ffmpeg fully supports HEVC [12:57:18 CET] <JEEB> officially [12:57:22 CET] <another> BtbN: well broadcast is using hevc [12:57:33 CET] <JEEB> videolan etc is providing binaries through VLC etc [12:57:43 CET] <another> so that's "something" [12:58:09 CET] <JEEB> dongs: does this stream really have the parameter sets at each packet? [12:58:19 CET] <damdai> btbn just said browser won't support hevc playingback because of "afraid to get sued" [12:58:21 CET] <JEEB> I'm looking through the trace headers log and I'm seeing this stuff pop up all the time [12:58:26 CET] <dongs> damdai: opensores 'usage' of HEVC & co to watch pirated anime and porn is so far off the radar of corporations that exist to make money, they don't even consider it worthwhile to pursue such "license violations" [12:58:44 CET] <dongs> jeeb, i'm not sure. i'm taking wahts in TLV, sequentially, and adding 00 00 00 01 to it. [12:58:50 CET] <JEEB> ok [12:58:54 CET] <dongs> http://bcas.tv/paste/results/Pe2f1A44.html [12:59:06 CET] <dongs> this is each complete mpu callback [12:59:12 CET] <damdai> dongs huh? no idea what you are trying to say [12:59:14 CET] <JEEB> I don't remember what the rules were wrt the start codes and if that matters [12:59:24 CET] <JEEB> the whole three/four byte thing [12:59:29 CET] <JEEB> but atl east trace headers isn't complaining [13:00:21 CET] <damdai> jeeb do you have any idea what dong just said [13:00:48 CET] <JEEB> he just says that enabling open source usage for most publicly available standards really isn't what the corps would be stopping [13:00:57 CET] <JEEB> they'd only then start paying attention to corps using that stuff [13:00:59 CET] <JEEB> (without a license) [13:01:14 CET] <JEEB> as in, OSS projects bring visibility, and wouldn't be able to pay anyways [13:01:27 CET] <dongs> precisely [13:01:53 CET] <damdai> and making a browser to support playingback HEVC is ???????????????? [13:02:01 CET] <dongs> jeeb, i have another reference mmt library from a settopbox, and they do similar [13:02:02 CET] <damdai> that, they care about? [13:02:15 CET] <JEEB> dolby and dts have their proprietary crap and they might throw a few papers at you if you reverse engineer their stuff, but yer usual standard formats don't do that [13:02:18 CET] <dongs> if divsiion = 0, append nal_prefix (00 00 00 01) [13:02:19 CET] <JEEB> (to OSS projects) [13:02:24 CET] <dongs> otherwise, copy copy copy [13:02:26 CET] <JEEB> ok [13:02:29 CET] <dongs> and if division == 3, commit [13:02:35 CET] <JEEB> so far I see no errors at least [13:02:36 CET] <dongs> and my code does same [13:02:59 CET] <fling> Is not it possible to send ioctl to an uvc device after opening it and before requesting v4l2 format? [13:03:08 CET] <JEEB> damdai: browsers are usually made by corporate entities (which f.ex. Mozilla is) [13:03:12 CET] <damdai> if some opensource webbrowser allowed to playback HEVC, would they really get sued? [13:03:16 CET] <JEEB> they have theiro wn lawyers and priorities [13:03:27 CET] <JEEB> like, an OSS project that's not a corp distributing something is one thing [13:03:36 CET] <JEEB> also of course different projects have different priorities [13:03:47 CET] <JEEB> and rules [13:03:53 CET] <JEEB> if a project doesn't want to support HEVC, it will not [13:03:57 CET] <damdai> how is mozilla corp any bigger than ffmpeg corp? [13:03:57 CET] <JEEB> there can be multiple reasons for it [13:04:04 CET] <JEEB> FFmpeg is not a corp [13:04:05 CET] <JEEB> at all [13:04:10 CET] <dongs> nobody actually uses mozilla tho [13:04:17 CET] <damdai> if ffmpeg is not a corp, then mozilla is not a corp either [13:04:20 CET] <JEEB> it is [13:04:35 CET] <damdai> it's opensource free browser [13:04:48 CET] <JEEB> yes, but the difference as a US company is wholly different [13:05:03 CET] <JEEB> this shouldn't be a weird thing nor hard to grasp [13:05:22 CET] <JEEB> https://en.wikipedia.org/wiki/Mozilla_Corporation [13:05:24 CET] <JEEB> mozilla, is a company [13:05:37 CET] <damdai> why doesn't firefox support MKV then? they are afraid to get sued by mastroka? [13:05:48 CET] <JEEB> no, that's just priorities [13:05:58 CET] <JEEB> they support webm already which is a subset of matroska anyways [13:06:23 CET] <JEEB> like, why are you asking this - how are we supposed to know why vendor X doesn't want to do Y? [13:07:21 CET] <JEEB> with video formats it's more clear because for AVC they've been vocal for not supporting it if only possible (which they then decided is not possible, and are using cisco's and the system's decoders for) [13:07:40 CET] <JEEB> GOOG is big enough to not care and just distributes a cut-down FFmpeg and pays the royalties :P [13:08:01 CET] <damdai> google pays ffmpeg ? [13:08:09 CET] <JEEB> no idea [13:08:28 CET] <JEEB> we don't care as long as they follow the software license as far as FFmpeg is concerned [13:08:32 CET] <damdai> you just google pays royalties to ffmpeg [13:08:34 CET] <JEEB> we're not licensing HEVC or AVC or anything else [13:08:36 CET] <damdai> you just said google pays royalties to ffmpeg [13:08:45 CET] <JEEB> no [13:08:48 CET] <JEEB> I said [13:08:58 CET] <JEEB> a) GOOG distributes a cut-down FFmpeg [13:09:05 CET] <JEEB> b) GOOG payts the royalties (without specifying where) [13:09:14 CET] <JEEB> probably MPEG-LA [13:09:22 CET] <JEEB> which is the primary licensing place for AVC [13:09:26 CET] <damdai> if goog distributes ffmpeg, should they be paying royalties to ffmpeg ? [13:09:31 CET] <TheAMM> ... [13:09:32 CET] <JEEB> no? [13:09:40 CET] <another> no [13:09:43 CET] <JEEB> all we want is that software license is followed [13:09:51 CET] <JEEB> which is either LGPL or GPL depending on the configuration [13:10:00 CET] <JEEB> GOOG uses LGPL and does abide by that [13:10:03 CET] <JEEB> as far as I know [13:12:20 CET] <damdai> does x265 have to pay money to hevc for making hevc encoder? [13:12:41 CET] <dongs> no. [13:12:45 CET] <dongs> cuz its not very good [13:12:46 CET] <damdai> why not [13:12:51 CET] <dongs> you only need to pay if you make something good [13:13:15 CET] <damdai> does x264 have to pay money to AVC for making avc encoder? [13:13:16 CET] <JEEB> dongs: anyways the stream itself seems to have valid NAL units structurally, but either you've combined the streams or something else is going on [13:13:28 CET] <damdai> dongs happy? [13:13:31 CET] <JEEB> damdai: the question is: do you distribute binaries and are you a corporation [13:13:49 CET] <JEEB> x265 and x264 officially do not distribute binaries [13:14:00 CET] <JEEB> -> thus at least under MPEG-LA you do not pay royalties [13:14:02 CET] <damdai> huh? of course they do [13:14:06 CET] <JEEB> no, videolan does [13:14:37 CET] <damdai> you mean they use videolan website/servers ? [13:14:50 CET] <JEEB> the building and distributing entity is videolan [13:14:51 CET] <damdai> instead of theirs? [13:15:03 CET] <JEEB> the x264 folk do not control the build bot etc [13:15:11 CET] <JEEB> nor do the x265 folk if there's a x265 build bot [13:15:11 CET] <damdai> why is videolan taking that responsibility? [13:15:19 CET] <dongs> JEEB: well, technically this is supposed to be a single video stream [13:15:20 CET] <damdai> that is stupid move on videolan part [13:15:31 CET] <JEEB> because they're in france and they've decided they don't care about patent licensing [13:15:34 CET] <dongs> there's the shit with multiple CIDs but (that particular hevc) was only from CID==2 [13:15:35 CET] <JEEB> just like with vlc [13:15:56 CET] <dongs> doing with cid==any also works and the file is jsut as unplayable [13:16:01 CET] <dongs> well, errors in ~similar palces. [13:16:02 CET] <damdai> did people attempt to sue videolan ? [13:16:06 CET] <JEEB> probably, no idea [13:16:17 CET] <JEEB> you should ask them if they wan to talk [13:16:18 CET] <dongs> damdai: whyt are you asking this anyway. does it personally affect / will affect you [13:16:36 CET] <dongs> trying to udnerstand waht youre trying to get at [13:16:39 CET] <damdai> dongs because i am curious [13:17:05 CET] <JEEB> although MPEG-LA is less likely to care about open source. other licensors might be less nice [13:17:17 CET] <fling> >> Option b:v (video bitrate (please use -b:v)) cannot be applied to input url /dev/video0 [13:17:19 CET] <JEEB> mostly looking at things like Dolby and DTS [13:17:22 CET] <damdai> jeeb then what country is x264/x265 located at? [13:17:27 CET] <fling> So I'm out of luck. [13:17:51 CET] <JEEB> damdai: x264 LLC which handles x264 licensing is in the US, x265 is developed my MultiCoreWare [13:17:56 CET] <dongs> fling, how would you even expect that to wrok [13:18:09 CET] <fling> dongs: via ioctl [13:18:09 CET] <JEEB> I think MCW is also legally a US corp [13:18:15 CET] <damdai> jeeb i see [13:18:25 CET] <damdai> this is still really stupid move on videolan's part [13:18:42 CET] <damdai> why would you take that responsibility [13:18:49 CET] <JEEB> because they think they don't need to care [13:18:54 CET] <JEEB> it's their decision [13:19:24 CET] <fling> dongs: ioctl (fd, UVCIOC_CTRL_QUERY, &xu) [13:19:28 CET] <damdai> videolan can just tell x26* : host the binaries on your own damn servers [13:19:46 CET] <JEEB> of course they can, but they rather reap the rewards if they don't need to care [13:20:01 CET] <damdai> what reward? [13:20:13 CET] <JEEB> awareness, and they're distributing that stuff through VLC binaries anyways [13:20:34 CET] <Martchus> Any idea what this error means? "[matroska @ 0x563513bfa400] Tag mp4s incompatible with output codec id '94208' ([0][0][0][0])" [13:20:36 CET] <JEEB> anyways, I'm not going to be able to answer instead of #videolan [13:20:52 CET] <JEEB> Martchus: you tried to stick something into mp4 that it didn't like? [13:21:02 CET] <JEEB> post full log and ocmmand line in pastebin or so [13:21:04 CET] <JEEB> and link here [13:21:07 CET] <damdai> i am very skeptic about VLC website: go to their VLC download page, it tells you how many people has downloaded VLC, and that number goes up 2 like very second [13:21:08 CET] <damdai> every* [13:21:09 CET] <Martchus> JEEB: you're fast :-) [13:21:17 CET] <Martchus> but let me provide the ffmpeg line first [13:21:24 CET] <JEEB> with full log thank you [13:21:28 CET] <JEEB> not onto the channel [13:21:32 CET] <JEEB> onto a pastebin gist or something else [13:21:35 CET] <JEEB> and link here [13:21:42 CET] <damdai> jeeb what do you think about that? [13:22:10 CET] <JEEB> damdai: I quite honestly do not give a flying fuck [13:22:27 CET] <Martchus> JEEB: of course pastebin, here you go: http://paste.opensuse.org/view//9158151 [13:22:37 CET] <JEEB> fling: ffmpeg -h demuxer=v4l2 gives you all of the parameters that you can give to the v4l2 thing [13:22:42 CET] <JEEB> anything else is not implemented [13:23:06 CET] <JEEB> and the bit rate not available for input proably is a global check so it'd have to have its own AVOption for it [13:23:23 CET] <JEEB> watches pelcome or a ticket on trac for a feature request [13:24:59 CET] <Martchus> JEEB: A assume "Tag" in the error message means "MP4 atom/element" and it is referring to the mp4s element in my file. [13:26:08 CET] <JEEB> it is the identifier that's being put somewhere [13:26:17 CET] <JEEB> but that is on the output side [13:26:28 CET] <JEEB> the message comes from matroska, not mov/mp4 [13:26:44 CET] <Martchus> interesting [13:26:59 CET] <fling> JEEB: can't I nasty hack into it somehow to just set the bitrate? [13:27:13 CET] <Martchus> so it seems that some mp4 element identifier couldn't be converted and therefore landed on the matroska-side where it can not be used? [13:27:26 CET] <Martchus> Btw, that's how the input mp4 file is structured: https://martchus.no-ip.biz/website/download.php?name=mp4-structure [13:27:46 CET] <JEEB> fling: you can hack it in the module, yes - most likely [13:27:55 CET] <JEEB> give it an AVOption and set to that value if nonzero or something [13:27:56 CET] <JEEB> :P [13:28:09 CET] <JEEB> but at that point you're pretty close to making it proper [13:28:30 CET] <fling> I'm not sure what AVOption is :P [13:28:42 CET] <JEEB> see at the end of libavdevice/v4l2.c [13:28:46 CET] <fling> And where should it be implemented then? Not in ffmpeg? [13:29:04 CET] <JEEB> "static const AVOption options[] =" towards the end of the file [13:29:17 CET] <fling> thanks, looking [13:29:17 CET] <Martchus> JEEB: oh, I almost forgot to say - using mp4 as output container works [13:29:22 CET] <JEEB> and just add yourself one and add it into the video_data structure [13:29:47 CET] <JEEB> fling: after you add an AVOption and re-build it should become visible in ffmpeg -h demuxer=v4l2 [13:30:00 CET] <fling> great! [13:30:17 CET] <JEEB> then you just make sure its type is right (int I guess?) and that it sets a value in struct video_data (that's how the context structure is called in v4l2.c) [13:30:53 CET] <JEEB> and then you can look at the v4l2_read_header function and within that check where you can add the bit rate setting [13:31:04 CET] <JEEB> and at that point you're more than half way there to a proper patch :P [13:31:25 CET] <JEEB> since you properly added a new AVOption, and are using it when initializing the v4l2 stuff [13:32:00 CET] <JEEB> Martchus: yes, there most likely is some issue for it to figure out something [13:32:03 CET] <JEEB> for some reason [13:32:16 CET] <JEEB> mp4 identifiers shouldn't matter since it already has the AV_CODEC_ID [13:33:11 CET] <dongs> JEEB: https://mega.nz/#!ldUDVQDR!KP1cLIgzC_Ska2tm9wW_arhAknOgDkClaiDX7YI4GXM (all cid) https://mega.nz/#!YVUFFYaI!ASbQejfHxVTlCMu4-SD-IXw65A1rn5yiNlr2LbDzA9s (cid=2) [13:33:14 CET] <dongs> from live capture [13:33:25 CET] <dongs> the (all cid) is significantly larger, and barely even tries to play [13:33:29 CET] <dongs> cid=2 at least has some attempt [13:33:40 CET] <dongs> i have no idea why ther would be multiple video streams here [13:33:43 CET] <dongs> makes no fuckign sense [13:33:59 CET] <dongs> does this POC thing have some kinda way to locate frames belonging to same stream? [13:34:03 CET] <Martchus> it seems that neither vlc nor mpv can actually play those subtitles - not sure what this strange mp4s subtitle format is anyways [13:34:17 CET] <JEEB> Martchus: someone hacked DVD subtitles into mp4 [13:34:39 CET] <JEEB> and it seems like because there's a "tag" set, it attempts to "validate" it in the global muxing code [13:34:45 CET] <JEEB> that's where the error is coming from [13:34:51 CET] <Martchus> JEEB: seems you're right - I've just opened media info and it is telling me that [13:35:01 CET] <JEEB> the ffmpeg.c output also told you that [13:35:05 CET] <Martchus> I always though doing that within mp4 wasn't possible [13:35:07 CET] <JEEB> Stream #0:3(eng): Subtitle: dvd_subtitle (mp4s / 0x7334706D) (default) [13:35:13 CET] <JEEB> Martchus: non-standard yes. very much [13:35:29 CET] <Martchus> so like vorbis in mp4 :-) [13:36:28 CET] <JEEB> also I like it how that message just dumps you the numeric codec id [13:36:36 CET] <JEEB> as if someone actually understands what that is [13:37:11 CET] <JEEB> oh that is not even an AVCodecID [13:37:17 CET] <Martchus> JEEB: you're right, ffmpeg is telling me the same [13:37:37 CET] <Martchus> and it works if I use "-c:s dvd_subtitle" instead of " -c:s copy" [13:37:45 CET] <dongs> hmm [13:37:50 CET] <JEEB> yes, because you lose the exact identifiers in the input stream [13:37:50 CET] <dongs> hevc frames in cid=1 are completely useless [13:38:38 CET] <Martchus> so problem solved or at least worked around - not sure whether this is a bug (the error message could be a bit more intuitive at least) [13:38:40 CET] <dongs> http://bcas.tv/paste/results/toE58S66.html [13:38:41 CET] <JEEB> ah no, that is actually the AVCodecID there [13:38:47 CET] <JEEB> (in the middle) [13:38:59 CET] <Martchus> JEEB: thanks for your help [13:39:07 CET] <JEEB> and the fun thing is that the matroska muxer most likely would just throw that "tag" into garbage anyways [13:39:14 CET] <JEEB> but the global code is checking for it [13:39:31 CET] <dongs> matroska is also a "input-only" thing as well [13:39:40 CET] <chrisaw> Hey folks - I've got a bit of an odd request. I have a bunch of DivX encoded videos at 512x384 resolution and 4:3 aspect ratio. What I want to do is convert them to widescreen (16:9) so that I can view them on my TV without the "pillarbox" effect. [13:39:45 CET] <dongs> good luck demuxing stuff like pgs subs etc out of mkv [13:39:53 CET] <dongs> or pgc/ or wahtever. [13:40:43 CET] <JEEB> Martchus: if you can, make a bug report on that at the trac pls [13:40:47 CET] <JEEB> (trac.ffmpeg.org) [13:40:59 CET] <Martchus> JEEB: ok, I'll do that later [13:41:05 CET] <JEEB> dongs: yea that looks like either broken or without separators [13:41:25 CET] <dongs> based on side, combined = 80megs, cid1 = 41megs, cid2 = 38megs [13:41:29 CET] <dongs> er size [13:41:38 CET] <dongs> but cid1 = just garbage, can't even decode [13:41:48 CET] <dongs> i have noo idea whats going on [13:41:59 CET] <dongs> i saw some patent/presentation about multiple streams [13:42:02 CET] <dongs> like 60fps and then 120fps [13:42:06 CET] <dongs> in same broadcast [13:42:16 CET] <dongs> but i dont think this is it... [13:42:38 CET] <JEEB> yea, using SVC for multiple layers or so [13:43:04 CET] <JEEB> (also US stations planning on using it to only encrypt some layers so that non-paying people can decode lower res) [13:43:12 CET] <dongs> https://www.nhk.or.jp/strl/publica/bt/bt61/pdf/fe0061-6.pdf [13:43:13 CET] <dongs> yeah this [13:43:25 CET] <JEEB> haha, that classic document [13:43:26 CET] <dongs> i dont think they're doing this tho? [13:43:43 CET] <JEEB> I would be surprised, and you should still be able to decode the base layer [13:45:21 CET] <dongs> who is the asshole who came up wtih mmt [13:45:25 CET] <JEEB> hahaha [13:45:28 CET] <JEEB> I've thought much of that too [13:45:29 CET] <dongs> this is by far the shittiest format like ever [13:45:37 CET] <JEEB> yes, it adds so much funky complexity [13:45:39 CET] <dongs> ATSC is also trying (?) to use it [13:45:39 CET] <JEEB> and to what end [13:45:40 CET] <JEEB> yes [13:45:44 CET] <JEEB> ATSC 3 has it also spec'd [13:45:50 CET] <JEEB> because patent royalties, most likely [13:45:52 CET] <dongs> and when i asked tsreader guy if hes ever gonna support it [13:45:52 CET] <JEEB> MPEG-TS running out [13:45:55 CET] <dongs> he told me like "fuck no" [13:45:59 CET] <JEEB> yes [13:46:02 CET] <JEEB> I expect that response [13:46:04 CET] <damdai> why does youtube have so many list of audio/video when doing youtube-dl _F [13:46:07 CET] <dongs> i was like [13:46:13 CET] <dongs> "what if im making hardware that will input tlv into your shit" [13:46:22 CET] <dongs> "oh just use mdplugin, read in mmt, remux to ts, and spit it back to me" [13:46:24 CET] <dongs> "..." [13:46:28 CET] <JEEB> :D [13:46:34 CET] <JEEB> löörs lärä [13:46:38 CET] <JEEB> as they say around here [13:47:28 CET] <JEEB> but yea, it's so much extra random complexity for no real reason. they would have gotten already quite far by just making a fork of MPEG-TS that has variable packet sizes like TLV [13:47:38 CET] <JEEB> but nope [13:47:52 CET] <dongs> they're not even realyl using variable packet length [13:48:51 CET] <JEEB> dongs: intersting [13:48:54 CET] <JEEB> the first thing you posted me [13:48:57 CET] <JEEB> the PID blah hevc [13:48:58 CET] <damdai> why does youtube have so many list of audio/video when doing youtube-dl -F [13:48:59 CET] <damdai> they need so much disk space already for all those uploaded video, but they need even more now having all those audio/video for each youtube video link [13:49:06 CET] <dongs> yeah [13:49:10 CET] <JEEB> has actual nuh_temporal_id_plus1 [13:49:12 CET] <BtbN> storage is dirt cheap [13:49:13 CET] <JEEB> of value 1 and 2 [13:49:14 CET] <BtbN> bandwidth is not [13:49:20 CET] <JEEB> let me check if that means two different thignamajigs [13:49:28 CET] <damdai> btbn lol storage is not cheap [13:49:44 CET] <BtbN> yes it is [13:50:25 CET] <DHE> damdai: well bandwidth is also at a premium. being able to meet the player's abilities - both codec and bitrate - has advantages to making users happy [13:50:41 CET] <BtbN> Just look at all the cloud storage providers. Storing 1TB for a month is like 5¬. But downloading the whole thing once is 20¬. [13:51:32 CET] <DHE> I suspect a lot of that is that storage providers don't want to be used as a makeshift CDN [13:52:01 CET] <BtbN> That's CDN rates though [13:52:08 CET] <BtbN> For S3 and the like [13:52:31 CET] <JEEB> dongs: ok no, that's just timewise identifier - the actual nuh_layer_id seems to be zero across board [13:52:37 CET] <BtbN> cold storage is cheaper to store, and costs even more to download [13:52:39 CET] <damdai> and if bandwidth cost so much money, how can they afford to host all those videos for free [13:53:08 CET] <DHE> the price of storage varies proprotionally to the speed of said storage... SMR hard drives vs Optane SSDs [13:53:09 CET] <BtbN> By monetizing them...? That's the whole point of the platform. [13:53:47 CET] <dongs> uhhh. [13:53:48 CET] <dongs> i think we got it [13:55:22 CET] <dongs> JEEB: https://mega.nz/#!VZ9EjC6K!ysoiCEyTjA-OBd9_5pIj3z252EeW7aGOlOCtaOR0z6s [13:55:36 CET] <dongs> they were storing some MORE of the video packets in hcf type 60 [13:55:38 CET] <dongs> .. as ipv6 [13:55:42 CET] <JEEB> :DD [13:55:45 CET] <dongs> what the fuck [13:55:54 CET] <JEEB> delicious brainfuck [13:55:56 CET] <dongs> but but [13:56:00 CET] <dongs> now i export wiht cid=all [13:56:03 CET] <dongs> and file is huger [13:56:05 CET] <dongs> but still palys same [13:56:11 CET] <dongs> so.. what is the EXTRA shit in cid=1 etc? [13:56:15 CET] <dongs> that makes it nearly 2x the size [13:56:34 CET] <dongs> lemme stick this one up [13:56:55 CET] <JEEB> and yes, this skapa HLG looks good to me in mpv [13:57:26 CET] <dongs> i dont even have a hdr monitor so i donno the difference [13:57:31 CET] <dongs> HDR shit just looks gray / muted [13:57:33 CET] <JEEB> neither do I but mpv tone maps real nice [13:57:56 CET] <dongs> https://mega.nz/#!Md8C0KpZ!X2p-yoAnMHDF5dtZN7_Vcjw7Kx53RV8VWwgh0ume-gE [13:58:09 CET] <JEEB> also I was just looking for more HLG samples, so thank you :) [13:58:21 CET] <dongs> eh [13:58:23 CET] <dongs> that last upload [13:58:26 CET] <dongs> instantly crashes mpv [13:58:30 CET] <dongs> but i ahave some version from 2017 [13:58:30 CET] <JEEB> rip [13:58:32 CET] <dongs> maybe i should upgrade [13:59:06 CET] <JEEB> the one with the initial ipv6 packets at least played on my build [13:59:10 CET] <JEEB> hwdec=d3d11va-copy [13:59:14 CET] <JEEB> because swdec is lol slow [13:59:29 CET] <damdai> if you have computerA and computerB in your own home: does it cost $$$ more money if you transfer 10TB of data from computerA to computerB instead of transfering 10 GB of data? [13:59:53 CET] <dongs> what [14:00:01 CET] <damdai> answer my question [14:00:02 CET] <dongs> damdai are you dumb, a student, or both? [14:00:30 CET] <dongs> ok still crashes mpv [14:00:31 CET] <dongs> hmm [14:00:37 CET] <dongs> but plays ok in mpchc [14:00:55 CET] <JEEB> for me it just fails to recognize PID-A001-MPU_all_cid_working.hevc as HEVC [14:01:10 CET] <DHE> both [14:01:18 CET] <JEEB> _ipv6 works [14:01:32 CET] <dongs> o yeah [14:01:34 CET] <dongs> i dropped it into mkv [14:01:36 CET] <dongs> and then it plays [14:01:54 CET] <dongs> so whats the extra bloat for? [14:01:59 CET] <dongs> if the cid=2 only shit plays too [14:02:14 CET] <dongs> its nearly 2x the size [14:02:25 CET] <dongs> couldn't be THAT much HDR data?? [14:02:31 CET] <JEEB> no [14:02:39 CET] <JEEB> it's HDR alright with the _ipv6 stuff [14:02:43 CET] <JEEB> mpv plays and tone maps that nicely [14:02:43 CET] <damdai> if i have computerA and computerB in my own home: it would cost me exactly same if i transfer 10TB of data from computerA to computerB instead of transfering 10 GB of data. so why is bandwidth more expensive than storage [14:03:05 CET] <JEEB> dongs: checking if those NAL units the parsers complains about are valid [14:03:13 CET] <JEEB> 27,26,58,12 [14:03:17 CET] <DHE> well if you transfer data between 2 local computers via internet storage, well yeah... [14:03:42 CET] <DHE> but even at gigabit speeds, 10 TB takes about a day to transfer [14:03:57 CET] <JEEB> where the fuck in the HEVC spec the list was again [14:04:11 CET] <dongs> about a day? lolwut [14:04:19 CET] <JEEB> ah yes, Table 7-1 [14:04:27 CET] <JEEB> NAL Unit type codes and NAL unit type classes [14:04:34 CET] <DHE> dongs: google for: "10 TB / 1 gigabit per second" [14:05:10 CET] <JEEB> 24 to 31 is "Reserved non-IRAP VCL NAL unit types" [14:05:23 CET] <JEEB> same for 12 [14:05:56 CET] <JEEB> 58 is just in the 48..63 range of "unspecified" [14:06:24 CET] <JEEB> so either it's garbage that's getting misparsed, or something else [14:07:01 CET] <dongs> JEEB: the B32/B60 probably mention what they are [14:07:11 CET] <dongs> or the one about multimedia coding [14:07:14 CET] <dongs> that covers HEVC wank [14:07:42 CET] <dongs> B32 most likely [14:08:06 CET] <JEEB> yea, HEVC spec just says to ignore as far as I can tell [14:09:24 CET] <damdai> is x265 really bad encoder like btbn/dong is claiming [14:09:52 CET] <JEEB> it's the least bad HEVC encoder that I know of. last I tested in 2017 it still had issues with detail retention, though :P [14:10:14 CET] <damdai> what is "detail retention" [14:10:51 CET] <JEEB> exactly what it says on the tin - keeping details around :P [14:10:51 CET] <DHE> not blurring or smudging the video. [14:11:06 CET] <DHE> can you see individual hairs, or is the top of my head just a colour blob [14:11:25 CET] <BtbN> damdai, I never claimed that. [14:11:38 CET] <damdai> if x265 causes "blurring/smudging" that's a serious issue [14:11:42 CET] <BtbN> I only commented about the patent/license mess around h265 [14:12:03 CET] <JEEB> it's an issue for some use cases and whether the users care [14:12:04 CET] <damdai> btbn was it dongs then? i can't remember , it was either one of you [14:12:18 CET] <JEEB> for low bit rates you don't care about fine details anyways [14:12:38 CET] <JEEB> the problem is when you're going for higher bit rates and expect stuff to be retained :P [14:13:21 CET] <damdai> so current vp9 encoder is better than x265 ? [14:13:48 CET] <JEEB> no? [14:14:03 CET] <damdai> forgot the name of the vp9 encoder is called [14:14:08 CET] <JEEB> although I don't know about eve, only about libvpx [14:14:09 CET] <DHE> libvpx [14:14:18 CET] <JEEB> eve IIRC is more optimized (but not open source) [14:14:33 CET] <damdai> is libvpx the one that google uses? [14:14:49 CET] <JEEB> yes, it's theirs [14:15:06 CET] <damdai> does ffmpeg support both libvpx and eve ? [14:16:08 CET] <JEEB> there is probably a patch for eve, but since it's not open source it wouldn't be taken in most likely [14:16:10 CET] <damdai> i know one thing that is way better about x265 over x264 [14:16:26 CET] <damdai> version # system [14:16:49 CET] <JEEB> oh you have just changed nicknames. thank you, now I know to no longer waste time on you [14:17:10 CET] <JEEB> may you have a pleasant day [14:18:49 CET] <TheWild> hello [14:19:31 CET] <TheWild> is there a chance I can extract *raw* (!!!) teletext stream from a video? [14:20:07 CET] <JEEB> TheWild: the AVPackets should contain the contents of the PES packets [14:20:08 CET] <JEEB> so yes [14:20:21 CET] <JEEB> not sure if you can do it with ffmpeg.c [14:20:28 CET] <JEEB> since I don't think there's a raw format for teletext [14:20:55 CET] <JEEB> but you can make a simple API client that demuxes the MPEG-TS [14:21:05 CET] <JEEB> and dumps the PID's data... somewhere, somehow [14:21:14 CET] <JEEB> whatever the format is you want [14:29:00 CET] <TheWild> let's play the game then. ffprobe first https://gist.github.com/beyondlimits/2bc6fc2fa470a5aefb61059e435bd775 [14:29:26 CET] <TheWild> then ffmpeg: https://gist.github.com/beyondlimits/07d8ad061597cc5ca9f5f981371d1f07 [14:30:11 CET] <JEEB> I'm not sure what you expected with that ffmpeg.c command [14:30:24 CET] <JEEB> also what format are you expecting to get out of the teletext PES packets? [14:31:08 CET] <JEEB> as in, have you thought any further than dumping the contents of the PES packets into a file? [14:31:12 CET] <JEEB> do they have delimiters? [14:31:24 CET] <JEEB> is there actually a way of reading that stuff in after you have dumped it [14:31:47 CET] <JEEB> to separate the packets that you have dumped [14:37:42 CET] <sourabhboss> Hi [14:41:59 CET] <TheWild> JEEB: by raw format I mean't whatever data that TSV file contains that serves as teletext. I managed to extract the data to a separate MP4 file (no video, no audio, just teletext). [14:42:50 CET] <TheWild> It doesn't look like text anyway. In the heart I expected it to be ETS 300706 (ol' good teletext), but even stripping most significant bit doesn't yield any meaningful data. [14:42:54 CET] <JEEB> I have no idea how FFmpeg managed to push that into mp4 :P [14:43:24 CET] <JEEB> there's no standard mapping for DVB teletext in MP4 after all [14:43:29 CET] <TheWild> ffmpeg -i 20170728_202413TVP1\ HD.TSV -scodec copy -map 0:s:0 /tmp/ramfs/teletext.mp4 [14:43:30 CET] <JEEB> (as far as I know) [14:44:06 CET] <JEEB> yea, I'm not saying it didn't do something, but no idea what or how valid :P [14:44:22 CET] <JEEB> also please explain what exactly you want to do [14:44:23 CET] <JEEB> like seriously [14:44:36 CET] <JEEB> you have so far only asked to dump the raw PES data into a file, which I'm not sure how you'd parse [14:44:38 CET] <TheWild> that was likely incorrect [14:44:49 CET] <TheWild> now I did: ffmpeg -i 20170728_202413TVP1\ HD.TSV -scodec copy -an -vn /tmp/ramfs/teletext.mp4 [14:45:04 CET] <TheWild> that produced some more data, but fortunately not the whole video/audio stream ;) [14:45:25 CET] <JEEB> the first one looked more proper since it picked only the first subtitle stream (also you can map PIDs with -map "0#0x69" [14:45:38 CET] <JEEB> anyways, I'd love an explanation of what exactly you are planning to do [14:45:52 CET] <JEEB> otherwise it's really hard to help you or tell you how much you have to code yourself [14:45:55 CET] <JEEB> if anything [14:46:26 CET] <dongs> why would you go from ts to mp4 [14:46:43 CET] <JEEB> exact seeking? [14:46:46 CET] <JEEB> (without full indexing) [14:47:05 CET] <JEEB> also windows "cast to XXX" feature forces re-encoding with MPEG-TS so I just remux to mp4 :P [14:47:29 CET] <JEEB> although not always, but it tends to work less well for blu-ray MPEG-TS [14:48:21 CET] <JEEB> dongs: anyways he said he waned to dump the raw PES data from teletext stream and I wondered if he knew what he was asking for since I don't know if teletext data packets have any delimiters whatsoever :P [14:48:35 CET] <JEEB> most DVB teletext tools anyways read MPEG-TS [14:48:53 CET] <dongs> reminds me of the days when i was parsing raw VBI shit from analog captures [14:49:02 CET] <dongs> sounds: fucking boring [14:49:08 CET] <dongs> does anything still use teletext in 2019? [14:49:11 CET] <JEEB> yeq [14:49:23 CET] <JEEB> DVB teletext is used for captioning and random other shit [14:49:37 CET] <JEEB> because DVB subtitles are pictures [14:50:28 CET] <dongs> well, at least this is wehre ISDB shit is less retarded [14:50:48 CET] <dongs> (tho the whole iso2022-arib-character shit is a whole other layer of retarded) [14:50:53 CET] <JEEB> yes [14:51:03 CET] <JEEB> that is the last piece I need to find to integrate into lavc [14:51:05 CET] <dongs> but at least S3 stuff is all utf8 [14:51:08 CET] <JEEB> because I've got everything but the text stuff [14:51:11 CET] <dongs> no more garbage [14:51:28 CET] <JEEB> as in, the whole ARIB caption decoding but it left the text decoding to a random glibc out-of-band iconv module [14:51:33 CET] <JEEB> which is not upstream anywhere [14:51:40 CET] <JEEB> I'd use libaribb24 but that's LGPLv3 [14:51:48 CET] <JEEB> (even though all license headers are LGPLv2.1+) [14:52:27 CET] <dongs> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libaribb24.c isnt the version in ffmpeg 2.1? [14:52:28 CET] <JEEB> like, I'd rather focus on getting the ARIB caption decoding done within FFmpeg, but I have to care about the most boring part of it :P [14:52:43 CET] <dongs> oh never mind [14:52:46 CET] <JEEB> dongs: I made that wrapper but it's LGPLv3 [14:52:46 CET] <dongs> that isnt the actual library [14:52:49 CET] <dongs> thats the shit wrapping it [14:52:52 CET] <JEEB> yes [14:53:10 CET] <JEEB> there's an anonymous fork of FFmpeg having the actual decoder, but as I said it leaves the text decoding separate [14:53:16 CET] <JEEB> I wanted to start bringing that in [14:53:24 CET] <JEEB> since it seemed to be less shit than libaribb24 in the caption side [14:53:28 CET] <dongs> gnu/cancer [14:53:43 CET] <JEEB> more like author not 100% understanding licenses [14:53:49 CET] <dongs> well yes [14:53:55 CET] <JEEB> before the author went more or less dead he relicensed from GPLv3 to LGPLv3 [14:54:04 CET] <JEEB> but for inclusion within default FFmpeg config I need LGPLv2.1+ [14:54:44 CET] <JEEB> but yea there's a giconv module in the linuxtv repo that is OK license wise [14:54:47 CET] <JEEB> buut [14:54:49 CET] <JEEB> > gnu libc iconv [14:54:52 CET] <JEEB> > not in upstream [14:54:54 CET] <JEEB> ayy lmao [14:55:21 CET] <JEEB> the guy actually tried to push his stuff usptream, but got told once yes, then another guy said nope and he didn't try too hard then :P [14:55:48 CET] <JEEB> https://git.linuxtv.org/v4l-utils.git/tree/contrib/gconv/arib-std-b24.c [14:56:05 CET] <JEEB> you can guess how much interest I have in using my time trying to convert this into normal code [14:56:12 CET] <dongs> doesnt look too awful [14:56:30 CET] <dongs> but lol at those #defines of bits of functions [14:56:31 CET] <JEEB> well yes, then I noticed it uses glibc iconv's internal functions [14:56:36 CET] <dongs> does anyone coding iconv ever tried to debug their shit? [14:56:57 CET] <JEEB> I think that's some glibc way of "making adding functionality simpler" [14:57:01 CET] <JEEB> which I don't agree with [14:57:14 CET] <JEEB> "why yes include this .c file here and all sorts of other magic" [14:57:17 CET] <dongs> __glibc_unlikely () what is this shit [14:57:24 CET] <JEEB> they sprinkle that all over yes [14:57:25 CET] <dongs> is that some complier optimiztaion/hint stuff? [14:57:26 CET] <JEEB> yes [14:57:36 CET] <JEEB> (probably never benchmarked) [14:57:51 CET] <JEEB> but really, the module's author is cool since he did the job and even added unit tests [14:58:03 CET] <JEEB> the glibc iconv module framework is just a mess [14:58:17 CET] <TheWild> mp4 was a random pick that always worked [14:58:24 CET] <CoreX> whats the deal with this ricemuffinball person? [14:59:12 CET] <JEEB> dongs: this is as far as I got with putting that crap into FFmpeg but then I noticed it uses internal functions of glibc iconv in the other files https://github.com/jeeb/ffmpeg/commit/0567db70d474193e45dc0921b90b0619acfb0… [14:59:36 CET] <JEEB> or arrays [14:59:38 CET] <JEEB> extern const uint32_t __jisx0201_to_ucs4[]; [15:00:00 CET] <JEEB> or extern const char __jisx0208_from_ucs_tab[][2]; [15:00:16 CET] <dongs> i briefly recall looking at something like this ~years ago. and yeah it was doing some crazy shit like converting to ucs then back to something else [15:00:33 CET] <dongs> anyway it seems ~modern utf8/unicode has all the special arib chars [15:00:38 CET] <dongs> because in EPG that I see in S3 captures [15:00:45 CET] <JEEB> about yea [15:00:46 CET] <dongs> there's icons for [4K], 5.1 etc [15:00:54 CET] <JEEB> they got those into unicode most likely [15:00:54 CET] <dongs> that are just normal utf8 sequences [15:01:08 CET] <JEEB> anyways, seems like it's mostly arrays [15:01:13 CET] <JEEB> so I might get out of that by copying those local [15:01:21 CET] <JEEB> (I wonder if that will clash with the gnu libc lol) [15:01:27 CET] <JEEB> or well, I'll just renmae them [15:01:29 CET] <JEEB> :P [15:02:43 CET] <JEEB> ok, seems like I was lol tired then so if it's just extern arrays it wants that's not godawful [15:02:47 CET] <JEEB> just ugh work [15:03:01 CET] <JEEB> (also I will be getting UCS-2 out so I still need to convert that to UTF-8 [15:03:28 CET] <JEEB> but if I just require some iconv on top of that it should work [15:07:10 CET] <JEEB> dongs: also the old ARIB specs also had a UTF-8 mode but due to the stuff initially going to production in 2003 it never was used in the MPEG-TS stuff as far as I can tell. and by now there no longer is an issue with that, and thank goodness for that :P [15:07:57 CET] <dongs> yeah never seen utf in mpegts [15:08:24 CET] <dongs> its always been b24, plus some slight differences ebtween terrestrial and satellite stuff [15:08:43 CET] <dongs> i never cared about it beyond raw text, teh formatting/position/color stuff was all mindfuckey too [15:08:57 CET] <dongs> like, take simplest shit ever and make it so complicated nobody wants to look at it [15:09:05 CET] <JEEB> yup, all them commands [15:09:26 CET] <JEEB> I only apply font size and color in the libaribb24 wrapper right now [15:09:38 CET] <JEEB> (also I skip half-height text because it's most likely ruby) [15:10:39 CET] <JEEB> https://megumin.fushizen.eu/screenshots/arib_subs/mpv-shot0004.png [15:11:09 CET] <dongs> mpv does this shit natively? nice [15:11:13 CET] <dongs> eta to getting mmt support into it [15:11:25 CET] <dongs> :) [15:11:50 CET] <JEEB> I still have X patches to review in mpv to post a small fix that fixes the timings (the old logic that is there for adding duration for subtitles is derp'd) [15:12:13 CET] <JEEB> like, I saw the current logic for text subtitles and it just special cased closed captions (those that go into video) [15:12:20 CET] <JEEB> and I facedesk'd [15:12:56 CET] <JEEB> dongs: yea I just need to pick all my pieces to make a demuxer at some point for the MMTP bullshit [15:13:05 CET] <JEEB> then it gets into FFmpeg upstream and then mpv can play it [15:14:31 CET] <JEEB> dongs: also btw I found mpv cached subtitle decoders when switching between normal and 1seg subtitle streams with libaribb24. [15:14:39 CET] <JEEB> because libaribb24 for some reason doesn't pick the profile in runtime [15:14:48 CET] <JEEB> so if youswitch from fullseg captions to 1seg [15:14:52 CET] <JEEB> you get random bullshit [15:15:16 CET] <JEEB> it's kind of an mpv bug, but until now no other subtitle/caption format has had profiles that you need to initialize when decoding [15:15:27 CET] <dongs> heh, nice [15:15:38 CET] <JEEB> (the stuff I'm trying to bring into FFmpeg does this during runtime) [15:15:44 CET] <dongs> i totalyl forgot about existence of 1seg [15:16:01 CET] <JEEB> so as soon as I get the darn text decoding working I'm so pulling that stuff upstream [15:16:16 CET] <JEEB> if it works better than libaribb24 for the captions, I'm all for that [15:16:52 CET] <JEEB> (I have so many things I need to finish all over) [15:17:44 CET] <JEEB> dongs: yea there's also magical Profile B which they never finished specifying [15:17:55 CET] <JEEB> they just added it in the spec and then noted that it's never finished [15:18:02 CET] <JEEB> so you have Profile A (fullseg) [15:18:10 CET] <JEEB> Profile B (some mobile thing for cars or whatever?!) [15:18:13 CET] <JEEB> Profile C (1seg) [15:18:50 CET] <JEEB> dongs: and I wouldn't know otherwise if I just didn't have MPEG-TS with the whole mux dumped, which contains both the fullseg and 1seg programs [15:19:25 CET] <dongs> cars auto-switch between full/1seg based on signal strength [15:19:35 CET] <JEEB> yea, that's how it ended up with [15:19:36 CET] <dongs> had no idea there was some car-specific shit made [15:19:43 CET] <JEEB> seemed like Profile B was supposed to be what they wanted first [15:19:47 CET] <JEEB> or something [15:19:48 CET] <dongs> well, fullseg capture includes 1seg trash by default [15:19:52 CET] <dongs> in full mux [15:19:53 CET] <JEEB> yes [15:19:59 CET] <dongs> 1seg only reception will be missing PAT and some other trash [15:20:02 CET] <JEEB> also it totally has become "trash" by now [15:20:03 CET] <dongs> so you gotta generate that [15:20:14 CET] <JEEB> because even mobile devices do fullseg now [15:20:18 CET] <dongs> right [15:20:23 CET] <dongs> now its just a waste of bandwidth [15:20:31 CET] <dongs> further murdering mpeg2 1080i bitrates [15:21:04 CET] <JEEB> also it's funny how I got thanked in Japan once for helping some Indian graduate code up samsung's ISDB/ARIB stack by linking all the specs and explaining on IRC :P [15:21:09 CET] <dongs> and they fucked up during analog cutoff and didn't spec hevc or at least h264 into the mix [15:21:16 CET] <dongs> so now they're fucked for probably another decade [15:21:21 CET] <dongs> with 1440/1080i mpeg2 [15:21:30 CET] <dongs> while the rest of the world laughs at modern high tech japan [15:21:47 CET] <JEEB> I think that's just "let's not switch what we took into production" kind of thing. ARIB specs have had full HD H.264 for a while [15:22:01 CET] <JEEB> it's the "my grandma has a receiver from 2003-2005" kind of problem [15:22:06 CET] <JEEB> rather than anything else [15:22:52 CET] <dongs> back around early 2000s i explained some samsung? or LG? or something similar guy how to multi2 and ended up with a verilog core for doing that [15:23:06 CET] <JEEB> :D [15:23:10 CET] <dongs> ts in > ts out, multi2 in the middle [15:23:15 CET] <JEEB> yea [15:23:55 CET] <dongs> hmm so now that shit works ill get you your 22.2 channel audio sample [15:24:43 CET] <JEEB> wonder what they're using for it. [15:25:24 CET] <dongs> i had a table open showing it then my shit bluescreened. [15:25:40 CET] <dongs> found [15:26:01 CET] <dongs> https://i.imgur.com/72ZNbtu.png [15:26:09 CET] <JEEB> ah, so just AAC and no bullshit [15:26:15 CET] <dongs> LATM or wahtever thing [15:26:19 CET] <dongs> that needs header prepended [15:26:23 CET] <dongs> but yeah othewise should be same [15:26:29 CET] <JEEB> oh right, switched to ADTS to LATM :< [15:26:35 CET] <JEEB> *from ADTS to LATM [15:43:52 CET] <JEEB> Martchus: thank you for https://trac.ffmpeg.org/ticket/7783 [15:44:48 CET] <Martchus> JEEB: thanks for your help and providing ffmpeg :-) [15:47:39 CET] <Martchus> By the way, the hardware transcoding with ffmpeg and nvidia graphics cards seems to work very well. [16:03:51 CET] <TheWild> JEEB: holy crap, yes!! All the bytes have been mirrored then their most significant bit stripped. https://gist.github.com/beyondlimits/b444b9958a79b4e67afe345d81b181e6 [16:04:39 CET] <TheWild> Now there comes hunt for how to extract the pure stream, that is, without outlining container. [16:04:59 CET] <JEEB> do you even know if you have some packet boundaries in teletext? [16:05:04 CET] <JEEB> before you start writing that out [16:05:19 CET] <JEEB> because you ain't going to be doing shit with the data if you don't know where the data starts and ends [16:05:52 CET] <TheWild> yup, this is the second thing I have to figure out [16:06:21 CET] <JEEB> I feel like that's the second thing you have to figure out. and if the standard doesn't have a "raw format", you better check if there's a de facto "raw" format for teletext [16:06:47 CET] <JEEB> writing the PES packets' data out by itself is not hard [16:06:56 CET] <JEEB> TheWild: also what is your goal you're trying to get to? [16:07:20 CET] <JEEB> I've been trying to get this out of you so I can figure if there's a simpler way for you to get through this :P [16:07:53 CET] <MmtBloat> sup developers [16:08:03 CET] <JEEB> not many devs here, but ohai [16:08:15 CET] <JEEB> (most developers are afraid of INT loss due to random users' questions) [16:08:32 CET] <MmtBloat> when are you going to fix me [16:08:44 CET] <JEEB> lol [16:08:59 CET] <JEEB> MMTP is something I have a morbid curiosity in [16:09:09 CET] <MmtBloat> it's nasty [16:09:15 CET] <MmtBloat> not terrible but nasty [16:10:11 CET] <MmtBloat> arib doesn't realise how much pain STB manufacturers endure supporting MMTP [16:10:22 CET] <MmtBloat> all stb firmwares are trash [16:10:26 CET] <MmtBloat> dongs can attest to that [16:10:49 CET] <JEEB> it's just so much extra complexity nobody would want to do that work for free :P [16:10:58 CET] <JEEB> compared to MPEG-TS which was relatively straightforward [16:11:07 CET] <MmtBloat> doing filters in dvb is so easy in comparison [16:11:13 CET] <TheWild> extract the raw teletext stream whatever it is, pretty much like extracting raw radio stream from a pcap dump whatever it is (MP3, AAC, whatever). [16:11:13 CET] <MmtBloat> in mmtp, you can do filters in so many layers [16:11:32 CET] <MmtBloat> and it becomes a nightmare for the design of the middleware [16:11:34 CET] <JEEB> TheWild: yes but what do you want to do with it afterwards? [16:11:44 CET] <MmtBloat> you can transmit the same information in 4-8 different ways [16:11:49 CET] <JEEB> sounds like MPEG-DASH [16:11:54 CET] <MmtBloat> like the ipv6 vs ipv6_compressed scenario from earlier [16:12:27 CET] <JEEB> TheWild: the problem with MP3 and AAC is that you have actual raw bit stream formats for those [16:12:28 CET] <MmtBloat> tehre's also ipv4, ipv4_compressed and other shits [16:12:36 CET] <JEEB> yea, just on the TLV level [16:12:41 CET] <JEEB> and unlike MPEG-TS you don't have PID 0x00 [16:12:45 CET] <JEEB> which contains the indices [16:12:56 CET] <JEEB> IIRC the broadcaster's specification shall contain the index ID [16:13:00 CET] <JEEB> multicast I think [16:13:34 CET] <MmtBloat> tlv level is very easy [16:13:34 CET] <TheWild> play with it, extract information and maybe search for features my DVB receiver is unlikely to make use of. [16:13:39 CET] <MmtBloat> hcfb and beyond not so much [16:13:45 CET] <JEEB> yes [16:13:49 CET] <MmtBloat> no, you do have a pid 0 [16:14:03 CET] <MmtBloat> pid 0 contains a PA message with the PLT [16:14:07 CET] <JEEB> I thought that thing that contained the index of programs was not globally defined? [16:14:08 CET] <MmtBloat> the PLT is equivalent to the traditional PAT [16:14:18 CET] <JEEB> somethin something tune to multicast XYZ [16:14:18 CET] <MmtBloat> it points to MPTs, which are equivalent to traditional PMT [16:14:25 CET] <JEEB> don't remember which spec said that [16:14:33 CET] <JEEB> and then the ARIB spec mentions the default multicast to listen to [16:14:37 CET] <MmtBloat> packet_id 0 contains a PA mesage with PLT [16:14:54 CET] <MmtBloat> i can show you a PLT [16:15:13 CET] <TheWild> https://en.wikipedia.org/wiki/Packetized_elementary_stream - seems trivial to extract the data from [16:15:17 CET] <JEEB> yes [16:15:25 CET] <JEEB> TheWild: if you just want to see if you can grasp anything from raw teletext PES packet data then patch libavformat/rawenc.c [16:15:47 CET] <JEEB> add a "teletext" raw format :P [16:16:04 CET] <JEEB> I have no idea if anything reads that [16:16:11 CET] <JEEB> but it's possible to dump it out [16:16:35 CET] <JEEB> if you want to make your own simple dumper you don't even need that, just dump the contents of the AVPackets since you will get the contents of the PES packet already put into the packet's data [16:17:40 CET] <MmtBloat> JEEB: http://bcas.tv/paste/results/z5kdCh84.html [16:17:42 CET] <MmtBloat> ^ PLT [16:18:13 CET] <MmtBloat> it tells you where to find MPTs (PMT) [16:18:33 CET] <JEEB> TheWild: also looking at libavformat/supenc.c [16:18:49 CET] <JEEB> it seems like the made-up "raw" format for blu-ray subtitles does have its own magic [16:18:53 CET] <JEEB> for each packet [16:18:56 CET] <JEEB> which is not surprising [16:19:13 CET] <JEEB> if the packets have no beginning marker you can't really effectively parse them :P [16:19:26 CET] <JEEB> also you lose timestamp information [16:19:37 CET] <JEEB> the sup format is MAGIC+PTS+DTS [16:19:40 CET] <JEEB> and then the data [16:19:48 CET] <JEEB> oh, length of data too after DTS :P [16:21:04 CET] <JEEB> TheWild: I hope I'm explaining why you shouldn't just dump this data into a file... [16:21:10 CET] <JEEB> unless you know it has delimiters [16:21:27 CET] <JEEB> and even then, you lose the timestamps that are conveyed in the MPEG-TS container (pts) [16:21:46 CET] <TheWild> sure [16:21:53 CET] <TheWild> thanks for all JEEB [16:22:09 CET] <TheWild> what really surprised me today is the simplicity of PES packet format. [16:22:14 CET] <dongs> lol MmtBloat [16:22:37 CET] <TheWild> I previously assumed it to be way more complex [16:22:37 CET] <dongs> i see youve been busy trolling while im out [16:23:01 CET] <MmtBloat> sir? i never troll [16:23:16 CET] <MmtBloat> did i say anything that was untruthful [16:23:44 CET] <dongs> unfortunately, no [16:23:54 CET] <TheWild> I extracted the teletext data into mpg file (not mp4, not mts) and seems to match the PES specification, or at least begins with 00 00 01 [16:23:58 CET] <dongs> mmt is proven to be bloated trash [16:24:03 CET] <JEEB> anyways, I'll go have a walk while there's still light out here, and then do some mpv work -> maybe some TLV/MMTP hacking (although I wonder if we could get some vendor pay for an OSS implementation due to the bullshit it contains :P) [16:24:03 CET] <dongs> i still dont understand [16:24:19 CET] <dongs> what the extra nearly 40% of shit [16:24:21 CET] <dongs> is in cid=1 [16:24:28 CET] <dongs> that makes no visible difference to palyback [16:24:40 CET] <dongs> because only extracting a001 pid from cid=2 still plays flawlessly.. [16:24:48 CET] <JEEB> yea [16:24:53 CET] <JEEB> so it seems to be something else? [16:25:00 CET] <dongs> the _all vs _cid2 or whatever test files i uplaoded [16:25:09 CET] <dongs> it can't be, because cid=1 by itself isn't playable at all [16:25:12 CET] <JEEB> also the local AAC person said that the 22.2ch stuff probably is not a single stream [16:25:13 CET] <MmtBloat> i don't se the same extra stuff in cid=1 [16:25:18 CET] <MmtBloat> from which source file did you generate from? [16:25:21 CET] <dongs> 18 [16:25:25 CET] <dongs> and sapporo [16:25:34 CET] <MmtBloat> i only got 2 frames out of 18 that were in cid=1 [16:25:34 CET] <dongs> actually any of them from skachan [16:25:39 CET] <MmtBloat> are they packets != a001? [16:25:43 CET] <dongs> a001. [16:25:46 CET] <MmtBloat> not here [16:25:50 CET] <MmtBloat> you're using my code? [16:25:55 CET] <dongs> i even pasted the pic [16:26:05 CET] <MmtBloat> yes, but i couldn't generate the same thing [16:26:29 CET] <MmtBloat> i can send you my video_callback [16:26:32 CET] <dongs> i added if (pInfo->ContextId != 0x02) inside DecodeMpu [16:26:35 CET] <dongs> and return [16:26:40 CET] <dongs> and i #if0 that to get huge file [16:26:42 CET] <JEEB> dongs: related to the AAC stuff http://up-cat.net/p/48156976 [16:26:59 CET] <TheWild> I have to look at the source code of ffmpeg. It may contain really interesting stuff [16:27:05 CET] <TheWild> ^ someday [16:27:24 CET] <JEEB> it contains some completely abhorrent stuff, and also some awesomesauce [16:27:30 CET] <dongs> JEEB: allright lemme find the 22ch file. [16:27:55 CET] <TheWild> you mean it smells like a code mess? [16:27:56 CET] <dongs> now im actually curious. [16:28:06 CET] <TheWild> nah, can't be that bad [16:28:06 CET] <MmtBloat> is my aac generation broken too? [16:28:07 CET] <dongs> ffmpeg was written originally by that crazy french guy [16:28:10 CET] <MmtBloat> they played fine here [16:28:18 CET] <dongs> fabrice something or other [16:28:22 CET] <MmtBloat> fabrice bellard [16:28:35 CET] <MmtBloat> the guy who wrote isdb/dvb/bla modulator/demodulateor library for dektec [16:28:35 CET] <JEEB> TheWild: the older a file goes the more funky it is [16:28:57 CET] <dongs> well aware [16:28:59 CET] <JEEB> and then we let some crap past because nobody cares/has time to review that stuff [16:29:07 CET] <JEEB> and someone cares enough [16:29:38 CET] <JEEB> MmtBloat: if it's multiple streams then that sub-stream should be playable [16:29:44 CET] <JEEB> I mean, one of them [16:29:53 CET] <MmtBloat> are we talking about video or audio? [16:29:56 CET] <JEEB> audio [16:30:12 CET] <JEEB> video in theory can have multiple layers as well, but I haven't gotten that far [16:30:32 CET] <MmtBloat> are you saying you found multi streams in the files from dongs? [16:30:32 CET] <MmtBloat> i'm lost for context [16:30:39 CET] <dongs> no, hes talkin about 22ch aac [16:30:40 CET] <JEEB> nah [16:30:43 CET] <dongs> and how thats gonna be represented [16:30:47 CET] <MmtBloat> oh [16:30:47 CET] <dongs> im booting the other shit now [16:30:50 CET] <dongs> will save the 22ch recording [16:30:53 CET] <MmtBloat> then never mind [16:31:08 CET] <JEEB> also this feels so absurd seeing MMTP actually in use :P [16:31:09 CET] <MmtBloat> is this 22ch shit related to isdb? [16:31:16 CET] <dongs> yes [16:31:20 CET] <MmtBloat> coming from japan, it's not absurd at all [16:31:20 CET] <dongs> the BS4K 22ch thing [16:31:25 CET] <MmtBloat> it's logical in fact [16:31:25 CET] <dongs> its 22.2 ch audio [16:31:26 CET] <dongs> as in [16:31:29 CET] <dongs> 22 speakers [16:31:29 CET] <MmtBloat> really [16:31:30 CET] <dongs> and 2 LFE [16:31:31 CET] <dongs> yes [16:31:32 CET] <MmtBloat> what's a filename with that on? [16:31:36 CET] <dongs> thats what im getting to [16:31:37 CET] <MmtBloat> longshit4? [16:31:38 CET] <dongs> nope [16:31:39 CET] <MmtBloat> 5? 8? [16:31:41 CET] <dongs> it hasnt been saved [16:31:44 CET] <MmtBloat> ah ok [16:32:05 CET] <JEEB> MmtBloat: unfortunately MMTP is not limited to Japan, although Japan has taken it into most use (I haven't seen the amount of ATSC test airings though) [16:32:24 CET] <dongs> tsreader guy says while mmt in atsc exists, its not used [16:32:30 CET] <dongs> tehre's some exception that allows ts in mmt [16:32:35 CET] <dongs> and everyone (so far) is doing that [16:32:36 CET] <JEEB> :D [16:32:46 CET] <MmtBloat> for japan, i'm saying it makes sense [16:32:50 CET] <MmtBloat> because they never make the right decisions [16:32:56 CET] <JEEB> ARIB specs also separate next-gen airings in MPEG-TS and MMTP [16:33:00 CET] <JEEB> so the spec (in theory) contains both [16:33:05 CET] <MmtBloat> they always go for the most idiotic complex bloated solution posible just to piss people off [16:33:38 CET] <JEEB> talking of that, I """loved""" the multimedia data airings [16:33:41 CET] <MmtBloat> we also have evidence that mmtp in isdb might be encapsulated by ts [16:33:42 CET] <dongs> ok its gonna be 7,8 from the back [16:33:51 CET] <MmtBloat> we don't know if it's naturally like that or if it's introduced by the tuner/demod [16:34:02 CET] <dongs> demod [16:34:06 CET] <JEEB> :) [16:34:14 CET] <dongs> the stuff with 188ts encapsulation was different demod [16:34:24 CET] <MmtBloat> you think it's the demod adding it? [16:34:34 CET] <dongs> almost certain [16:35:10 CET] <MmtBloat> it's sad that their DRM is easier to hax than their MMTP bloatware [16:35:20 CET] <MmtBloat> tells you a lot about mmtp in itself [16:35:31 CET] <JEEB> yes [16:35:47 CET] <JEEB> I think I've been rambling to my coworkers about MMTP since... 2016 or so? [16:37:03 CET] <MmtBloat> we got the drm down in a week or less [16:37:03 CET] <MmtBloat> but mmtp still causes us heacdaches more than a month later [16:37:37 CET] <JEEB> the first MMTP sample I got was from some random BD recorder and was crap as it was AACSv2 [16:37:48 CET] <dongs> well, i can give you a shitload now [16:37:51 CET] <JEEB> yup [16:37:55 CET] <MmtBloat> i was the one that told you it was garbage [16:37:56 CET] <JEEB> I have a couple from your links [16:38:06 CET] <MmtBloat> i gave you a normal tlv header that wasn't broken [16:38:41 CET] <MmtBloat> dongs: when can you do another ap with tuner #1, to check quality again? coz we were misled by my bug [16:38:45 CET] <MmtBloat> ap=cap [16:39:35 CET] <dongs> right... and now my fpga shit is weird [16:39:41 CET] <dongs> there's definitely problems with that way tho [16:39:42 CET] <MmtBloat> ah, still? [16:39:44 CET] <dongs> i.e. hoise stuff [16:39:45 CET] <dongs> noise [16:39:46 CET] <dongs> yeah [16:39:52 CET] <MmtBloat> what about tuner #2, did you fix "No data" bug? [16:40:13 CET] <dongs> still no data in signal check. but so far normal capture looks ok [16:40:26 CET] <dongs> (even the ~70mbit stuff from skachan, so other shit works as well [16:40:28 CET] <MmtBloat> ah, so we can't get 8k is the only problem? [16:40:29 CET] <dongs> no tlv sync errors etc. [16:40:31 CET] <dongs> yes [16:40:34 CET] <MmtBloat> nice [16:42:15 CET] <MmtBloat> it's a shame they don't have porn in 8K [16:42:19 CET] <MmtBloat> coz im sure Jeeb would accelerate efforts to fix mmt [16:42:21 CET] <MmtBloat> y/n/m [16:42:34 CET] <dongs> haha [16:42:54 CET] <dongs> i think.. theer's some half naked jappu dudes at those festivals [16:42:58 CET] <dongs> if he swings that way [16:43:55 CET] <JEEB> anyways, lawl [16:44:13 CET] Action: JEEB will take a hike for a moment while it's still possible and then will review ~100 commits in mpv [16:44:18 CET] <JEEB> then we might talk TLV/MMTP :P [16:44:47 CET] <MmtBloat> if you give me permission, ill insta reject those commits [16:44:51 CET] <MmtBloat> or approve, whichever you prefer [16:44:54 CET] <MmtBloat> and then you're free [16:45:09 CET] <JEEB> it'll probably be an approval since we want those features in :P [16:45:17 CET] <JEEB> (leftovers from the ex-main author) [16:45:28 CET] <dongs> what is mpv anyway, just a frontend to ffplay? [16:45:41 CET] <JEEB> mplayer -> mplayer2 -> mpv [16:45:56 CET] <kepstin> no relation to ffplay at all [16:45:56 CET] <JEEB> it's an FFmpeg API client like ffplay but it doesn't share legacy at all with ffplay [16:46:01 CET] <dongs> is mplayer opposite of mencoder? (same people [16:46:05 CET] <JEEB> yes [16:46:16 CET] <dongs> ok, now i got my orientations correctly so i know who to look down at [16:46:34 CET] <MmtBloat> my question is, does mpv support Motif/X11? [16:46:40 CET] <dongs> say wat [16:46:43 CET] <JEEB> no idea and not sure if I care [16:46:46 CET] <MmtBloat> if not, nobody's going to use it in lunix [16:46:53 CET] <JEEB> we have DRM support for the embedded people [16:47:00 CET] <JEEB> (which is weird enough for me) [16:47:38 CET] <dongs> DRM is that shitty linux acceleration api? [16:47:45 CET] <MmtBloat> how any rendering frameworks are there in lunix [16:47:47 CET] <kepstin> MmtBloat: mpv runs on X11 fine, but it doesn't use a Motif ui (it doesn't use a ui toolkit - it draws its as osd over the video) [16:48:10 CET] <MmtBloat> someone didn't pick up on the /s ;) [16:48:20 CET] <kepstin> ... [16:48:49 CET] <kepstin> you know what, someone new to put on my ignore list (that's not sarcasm, btw) [16:49:27 CET] <MmtBloat> oh noes he thinks he hurtz my feelings :) [16:49:37 CET] <JEEB> anyways, out for a bit [16:49:53 CET] <dongs> haha, kepstin does the standard opensource reaction to criticism [16:50:00 CET] <MmtBloat> indeed [16:50:23 CET] <kepstin> that wasn't criticism, that was just trolling. [16:50:27 CET] <MmtBloat> must be one of those rabids who has a RMS tshirt and poster up their wall [16:50:32 CET] <dongs> I guess I need to revisit MH-Audio descrpitor shit [16:50:41 CET] <dongs> i dont see where im matching 22.2 ch code in my parsing [16:50:51 CET] <dongs> i probly just skipped over it [16:51:13 CET] <MmtBloat> we need to revisit the way we look for descriptors [16:51:27 CET] <dongs> that too [16:51:33 CET] <dongs> but its better to have them prepared either way [16:51:39 CET] <dongs> the parsing isnt gonna change much [16:51:45 CET] <MmtBloat> i sugest we go for the old one [16:51:56 CET] <MmtBloat> just do a find_descriptor() [16:52:12 CET] <MmtBloat> coz the app should drive what it wants [16:52:17 CET] <MmtBloat> rather than the sdk supporting everything [16:53:24 CET] <MmtBloat> it's a good thing kepstin doesn't live in japan [16:53:32 CET] <MmtBloat> coz we wouldn't to be supporting such narrowminded people [16:53:37 CET] <MmtBloat> wouldn't want [16:55:59 CET] <dongs> component_type covers 22ch stuff. i read it but didnt print out the details [16:56:03 CET] <dongs> cuz it lokoed boring [16:56:12 CET] <MmtBloat> do i have a recording with that? [16:56:24 CET] <dongs> you're about to [16:56:27 CET] <dongs> its on the way [16:56:36 CET] <MmtBloat> ok [16:56:42 CET] <souvikhaldar> Can I add effects and filters to video like Instagram or snapchat using ffmpeg? [16:56:47 CET] <MmtBloat> make sure you name the file not-for-kepstin.tlv [16:57:04 CET] <durandal_1707> stop bulling or be kicked! [16:57:26 CET] <Kam_> Hi, I'm facing the issue described here https://superuser.com/questions/1411133/ffmpeg-invalid-length-0x59f0-0x8bd7… I'd say it happens when FFmpeg is reading near the end of the MKV/WebM file, can anyone look into this, please? [16:57:59 CET] <MmtBloat> kick away man, i'll be out of here after today [16:58:07 CET] <MmtBloat> it will also limit how muhc i help dongs get data for jeeb [16:58:10 CET] <MmtBloat> such wonderful people here [17:01:01 CET] <MmtBloat> wouldn't be the first time opensores shit where they eat coz they have no sense of humour [17:01:07 CET] <MmtBloat> and with that, i'm going to play apex with spawn [17:03:36 CET] <souvikhaldar> anyone help me with this? http://34.219.22.227/ [17:04:09 CET] <dongs> how much are you paying, souvikhaldar ? [17:04:16 CET] <dongs> because that sounds like actual work [17:05:30 CET] <souvikhaldar> No I just need to write system design document hence needed help from ffmpeg people [17:05:52 CET] <souvikhaldar> It would be really helpfull if you can just suggest the path [17:06:06 CET] <souvikhaldar> dongs: [17:06:47 CET] <dongs> so JEEB i think its in 3 streams [17:06:49 CET] <dongs> 22.2ch 3/3/3-5/2/3-3/0/0.2 [17:06:52 CET] <dongs> this is what they call 22.2 [17:07:32 CET] <dongs> gonna printf that shit from audio descriptor and see [17:09:30 CET] <dongs> Event: ð+Ù¹ÈŠ€óÉü+ò¢ëÐàLíüšó°êóð¢ð ð§ [17:09:33 CET] <dongs> Description: +ò¢ëÐàLíüšó°êóïü°Êü\òSnBo+njD+;êg JJQ"3+goijjDën Ïhóÿg#å>- [17:09:37 CET] <dongs> Descriptor MH-Audio component Descriptor (tag 8014, length 10) [17:09:40 CET] <dongs> Component Tag: 0010, Stream Type: Sound stream by MPEG - 4 AAC Audio Mode: 3/3/3-5/2/3-3/0/0.2 mode, Sample Rate: 48 kHz [17:09:43 CET] <dongs> wooh spam [17:09:45 CET] <dongs> sorry. [17:09:48 CET] <dongs> :) [18:11:17 CET] <JEEB> dongs: funky stuff :) [18:11:49 CET] <JEEB> 8K wagner [18:43:27 CET] <faLUCE> hello. does opus encode without òatency? [18:43:48 CET] <faLUCE> latency [18:44:43 CET] <DHE> there's a latency/delay option -opus_delay [18:44:49 CET] <DHE> so set it low [18:45:06 CET] <faLUCE> DHE: but how much low can it be ? [18:45:38 CET] <DHE> according to the built-in help, 2.5 milliseconds is the minimum [18:46:11 CET] <faLUCE> for example, AAC requires a minimum of 45 ms at 44100 [18:46:29 CET] <faLUCE> ok thnks [18:46:53 CET] <DHE> well that's more because it encodes 1024 samples at a time... but still, 45ms seems a little bit high.. [18:47:10 CET] <faLUCE> DHE: it's in the AAC specs [18:53:21 CET] <another> faLUCE: keep in mind that the lowest is 5ms [18:54:03 CET] <another> 2.5ms is just the lowest frame size [18:56:07 CET] <faLUCE> ok, it's good in each case [18:56:49 CET] <faLUCE> does it work with mpegts container? [18:57:43 CET] <another> i think there is a mapping [18:57:49 CET] <another> but i'm not sure [18:58:12 CET] <faLUCE> what do you mean with mapping? [18:59:02 CET] <DHE> mpegts as a container basically has a single byte (officially) to indicate the codec. so there needs to be a value reserved for it to map to 'OPUS' [18:59:37 CET] <faLUCE> DHE: then it doesn't support OPUS without a hack [19:00:04 CET] <faLUCE> which container could I use for opus? [19:00:09 CET] <DHE> mpegts is the muxer used by over-the-air broadcasts. I wouldn't rely on it to support anything not standardized by the sorts of bodies that handle that. [19:00:21 CET] <DHE> (plus unless you're doing realtime streaming, it's not that great a container anyway) [19:00:34 CET] <faLUCE> DHE: I do realtime streaming [19:00:57 CET] <faLUCE> it's well supported by lot of players [19:00:58 CET] <DHE> in retrospect that makes sense if you're asking for low latency encoding [19:01:32 CET] <faLUCE> DHE: ok, but I need a realtime streamer as well [19:02:46 CET] <faLUCE> I need to stream h264 + opus [19:03:19 CET] <kepstin> note that at 30fps video, you're still talking about 16ms/frame, so there's no really much reason to use lower latency than that in the audio codec if you want a/v sync anyways [19:03:24 CET] <faLUCE> I don't know if I still should use mpegts or if there's a better container [19:03:47 CET] <faLUCE> kepstin: I know, I already made a realtime player+ streamer [19:04:02 CET] <faLUCE> kepstin: but I want to switch to opus because AAC is 45ms minimum [19:06:30 CET] <kepstin> are you sending mpeg-ts in udp right now? [19:06:40 CET] <kepstin> might make sense to look at rtp instead [19:06:42 CET] <another> faLUCE: also, you might want to use libopus instead of the experimental opus encoder [19:07:52 CET] <faLUCE> kepstin: I use udp [19:08:14 CET] <faLUCE> and I receive all with the expected latency [19:08:26 CET] <faLUCE> which is 45ms, with A/V in sync [19:08:46 CET] <faLUCE> now I want to reduce it to 16ms, by using opus [19:08:59 CET] <faLUCE> but I don't know if I should use mpegts [19:54:43 CET] <JEEB> DHE: opus-in-mpeg-ts is specified for the record [19:55:07 CET] <DHE> oh? that's a surprise... [19:55:23 CET] <DHE> now I want to see if my equipment can support it. :) [20:01:56 CET] <Kam_> is there any documentation for sws_flags param0 and param1? All I could find was in the source code here https://github.com/FFmpeg/FFmpeg/blob/a0ac49e38ee1d1011c394d7be67d0f08b2281… [20:02:53 CET] <JEEB> DHE: I think the funniest part was where after all the procedures and payments etc after a year or so they "accidentally" removed it from their page :D [22:22:57 CET] <L29Ah> can ffmpeg audio filter be used as an ALSA plugin? [22:23:16 CET] <JEEB> if you make a module for that in alsa I guess? [22:37:30 CET] <ossifrage> Does anyone know of a codebase that uses libavformat to multiplex h.264 elementary frames into mp4? I'm bludgeoning my way through it, but I have no clue if what I'm doing is right [22:38:43 CET] <ossifrage> I've used the ffmpeg API to do encoding in the past without any pain, but just doing the multiplexing is being overly painful [22:39:50 CET] <JEEB> I don't see what's anything special with that? you open an output avformat context with the mp4 format, you add an AVStream, set parameters to the new stream's codecpar, set a time base for the stream [22:40:06 CET] <JEEB> after that you can call av_dump_format with the relevant context [22:40:12 CET] <JEEB> (to see how it looks to AVFormat) [22:40:36 CET] <JEEB> then you write the header, and write packets (with av_interleaved_write_frame) [22:41:03 CET] <JEEB> after you have finished, you flush with a NULL to av_interleaved_write_frame [22:41:12 CET] <JEEB> and finally write trailer to finish up the mux [22:41:36 CET] <JEEB> (of course AVPackets you give to interleaved_write_frame have to have a buffer, stream index, dts+pts+possibly duration around [22:41:41 CET] <ossifrage> I wouldn't think it would be anything special, I got something that takes a file in and writes a file out, but it is gross and has a bunch of the old api in it [22:43:09 CET] <JEEB> also specifics depend on what you're exactly doing, but that's the overall gist. if you already encode the stream with AVCodec then you can copy the parameters from your encoder AVCodecContext to the codecpar for the stream [22:43:10 CET] <ossifrage> I'm trying to get live streaming to a browser to work, so I need to output a live fmpv stream [22:43:36 CET] <JEEB> so one of the AVOptions for fragmentation needs to happen, that's it [22:43:39 CET] <ossifrage> JEEB, the encoded data is coming from a hardware encoder (h.26[45]) [22:44:03 CET] <JEEB> which just means you will have to put that data into an AVPacket [22:44:03 CET] <ossifrage> I have the frame data (with some of the NALUs marked) and a PTS [22:44:42 CET] <JEEB> in the worst case if you don't trust yourself to make proper parsing of the stuff the encoder gives you, you can utilize the raw avc/hevc demuxer [22:44:49 CET] <JEEB> with a custom AVIO thing [22:45:00 CET] <JEEB> which means you can feed it buffers [22:46:21 CET] <ossifrage> Ages ago I did mp4 + rtsp without too much trouble using live555 and parsing the bitstreams is not overly painful [22:46:30 CET] <JEEB> since you're not doing encoding in AVCodec you'll have to do stuff like set the extradata buffer in the AVStream's extradata field yourself etc, but it just doesn't feel like anything too special :P [22:47:02 CET] <JEEB> otherwise it's generally just a case of not forgetting to set stuff like time base for the AVStream and have the AVPackets follow that (and have the stream index set) [22:47:30 CET] <ossifrage> JEEB, yeah, it is just a matter of figuring out what I need, so far I've been good at getting it to just segfault [22:48:23 CET] <ossifrage> My goal is to get this thing to output live DASH [22:49:49 CET] <JEEB> I've been poking people a lot to the transcoding example since if I recall correctly it doesn't try to do weird stuff like fread'ing a file instead of using the framework to read a file of specific format. I'm pretty sure the output avformat context related stuff in that example is exactly what you need, other than the stuff that you need to do with your custom AVPacket creation since your buffers of data [22:49:55 CET] <JEEB> come from elsewhere [22:50:20 CET] <JEEB> also for MPEG-DASH you either use the "dash" meta muxer, or set one of the fragmentation related AVOptions in the mp4 muxer [22:50:32 CET] <JEEB> depending on if you want the full shebang or just fragmented mp4 [22:51:37 CET] <ossifrage> I'm going to have 3 fp4 streams (h265 4k, h264 1080p, and something lowish bitrate) [22:52:16 CET] <JEEB> and of course since you're not having an existing AVStream from input nor an AVCodec encoder you will have to set stuff like the extradata and codec id and such into the codecpar of the AVStream you create [22:52:27 CET] <ossifrage> It kinda sucks that patent hell means that h265 isn't supported in chrome/firefox [22:53:15 CET] <ossifrage> yeah, the code I have now is using the codec stuff, I need to switch it to codecpar [22:53:40 CET] <JEEB> I don't even know how you get there :P [22:53:56 CET] <JEEB> since AVStream's don't really have an AVCodecContext at this point if I recall correctly. everything's using codecpar [22:54:15 CET] <JEEB> (in avformat) [22:54:56 CET] <ossifrage> it produces an output (file to file) but the PTS is some woo woo [22:55:11 CET] <JEEB> remember to scale your pts/dts/duration [22:55:23 CET] <JEEB> from your input time base to output time base [22:55:29 CET] <JEEB> there are helper functions for this [22:55:57 CET] <ossifrage> I'm going to start fresh, without touching any files [23:00:09 CET] <ossifrage> Even though transport streams are horrible, the are bloody easy to use [23:01:13 CET] <JEEB> also for the record, for decoding and encoding AVCodecContext is 100% kosher and you're handling such. but avformat deals with avcodec parameters [23:01:53 CET] <JEEB> (this is mostly because people kept re-using the AVCodecContexts from avformat back in ye olden days for decoding, which was not really correct usage as the avformat context owned the decoder instance utilized for probing etc :P [23:03:34 CET] <ossifrage> I was tempted to just punt and output rtsp, but I'm hoping the adaptive streaming stuff will be worth it [23:04:55 CET] <JEEB> anyways, I'm really sorry that you're having issues but unfortunately this seems like a relatively straightforward thing and by far the logic's covered in the examples. you have your own custom needs but so far all of them seem 100% possible :P [23:05:53 CET] <JEEB> with a quick thought I can think of at least two things that generate their own AVPackets etc from unrelated input [23:06:17 CET] <JEEB> vlc's avformat output module and nevcairiel's LAV Filters, which feeds those to a decoder [23:06:18 CET] <ossifrage> ohh, do tell :-) [23:11:30 CET] <ossifrage> Much of the fmp4/dash/hls stuff is just done with command line tools and not code based [23:12:19 CET] <JEEB> there really isn't much special with it :P you set required AVOptions to the output avformat context and be done with it [23:12:26 CET] <JEEB> then you feed it packets as usual [23:16:56 CET] <ossifrage> Thanks for the help, I appreciate it. I'll feel much better when this thing is streaming proper video [23:17:39 CET] <ossifrage> I've been either streaming the video over ssh to a mpv or using web based motion jpeg (40mbps 720p doesn't look bad) [23:42:41 CET] <norbert> hi, I'd like to get a very recent version on my CentOS 7.6 [23:43:20 CET] <norbert> I already ran: https://paste.debian.net/1072625/ [23:43:24 CET] <JEEB> IIRC someone provided 64bit builds for linux that were relatively static, otherwise you'll have to build yourself which shouldn't be too bad [23:43:44 CET] <JEEB> yea no idea about rpmfusion :P [23:43:59 CET] <norbert> ...but ffmpeg --version still replies 3.4.5 [23:45:28 CET] <JEEB> then that's what's being packaged in wherever you installed it from? [23:45:36 CET] <JEEB> that doesn't really have anything to do with FFmpeg itself [23:46:31 CET] <JEEB> the main page seems to link these builds, but as usual I have no opinion on them https://johnvansickle.com/ffmpeg/ [23:54:52 CET] <norbert> ok [00:00:00 CET] --- Mon Mar 11 2019

1 0

ffmpeg-devel.log.20190310
by burek 11 Mar '19

11 Mar '19

[00:19:24 CET] <philipl> btbn: https://trac.ffmpeg.org/ticket/7778#comment:10 [00:19:32 CET] <philipl> We should update that error message? [00:20:18 CET] <BtbN> With the version? Yeah. [00:20:23 CET] <philipl> yeah [00:20:34 CET] <BtbN> more ifdefs [00:33:20 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/553f17c6a6db1901f191252aef1ee30723… [00:34:51 CET] <cone-849> ffmpeg 03Timo Rothenpieler 07master:1144d5c96d2a: avcodec/nvenc: add minimum driver version for SDK 8.2 and 9.0 [03:52:10 CET] <relaxed> There's a person with a patch in #ffmpeg inquiring how long it takes to be authenticated to post on trac. Any idea? [11:38:35 CET] <BtbN> relaxed, I'm not aware of trac needing any kind of authorization to post after registration. Besides, trac is not where patches go. [12:14:41 CET] <durandal_1707> CyberShadow: nice filter [12:14:57 CET] <CyberShadow> Thanks :) I'm still working on it. [14:49:42 CET] <BradleyS> CyberShadow: which filter are we talking about? [14:50:00 CET] <JEEB> the ticket mentioned right before paul's comment most likely [14:50:32 CET] <BradleyS> i have the ticket bot muted, link pls? [14:51:00 CET] <BradleyS> have to remember which bot that is and unmute it again [14:51:07 CET] <BradleyS> fflogger? [14:51:58 CET] <JEEB> yea [14:52:10 CET] <JEEB> https://trac.ffmpeg.org/ticket/2104 [14:53:11 CET] <BradleyS> ty [14:53:26 CET] <BradleyS> ooo that is a nice filter CyberShadow :) [15:27:52 CET] <JEEB> seems like .jp is using plain old AAC for 22.2 https://i.imgur.com/72ZNbtu.png [16:04:52 CET] <atomnuker> JEEB: definitely not a single standard stream then [16:05:24 CET] <atomnuker> with pce you get 16 channels max, and you also have a limit of 511kbps for the entire stream [16:05:34 CET] <JEEB> I should be getting a sample today [16:05:38 CET] <JEEB> we'll see how it goes [16:23:53 CET] <gnafu> JEEB: Ooh, cool! [16:24:31 CET] <gnafu> The most I've ever had was 7.1. It was nice, but I'm actually more happy with my current 3.0 setup (aside from missing the subwoofer). [16:25:05 CET] <gnafu> The front soundstage is the most important for me, and I've found a decent mix (or processor) can make 2.0 or 3.0 sound like it's surrounding you. [16:25:33 CET] <gnafu> I am interested in experiencing overhead channels in a home theater environment, though. I can see where that would be more difficult to emulate with two speakers. [16:30:03 CET] <BradleyS> outlaw audio model 975 [16:30:25 CET] <BradleyS> folds multichannel into beautiful stereo if you want it too [16:30:30 CET] <BradleyS> to* [16:31:09 CET] <BradleyS> pair with a good power amp and big quality speakers [16:31:21 CET] <BradleyS> completely gave up my 5.1 setup [16:33:29 CET] <gnafu> BradleyS: :-D [18:29:50 CET] <j-b> durandal_1707: it seems there are actually only a few AC-4 samples in existence :) [18:30:08 CET] <JEEB> j-b: fyi I am getting more and more samples of the insanity that is MMTP over TLV [18:30:22 CET] <JEEB> since some Japanese channels are actually airing it [18:30:42 CET] <j-b> I've seen that too. [18:30:56 CET] <j-b> JEEB: I'm wondering when do we start an open source library to maintain this crap? [18:31:49 CET] <JEEB> now seems to be a time when you could in theory start implementing it since it's in actual use (as opposed to a random sample here and there) [18:32:17 CET] <JEEB> also 22.2ch audio seems to be 3/3/3-5/2/3-3/0/0.2 [18:35:52 CET] <durandal_1707> j-b: ac4 is in broadcasting [18:36:02 CET] <j-b> yes [20:11:59 CET] <jamrial> scheduled weekend ml drama [20:20:23 CET] <durandal_1707> usual suspect(s) [20:44:15 CET] <cone-690> ffmpeg 03Michael Niedermayer 07master:0be0197f49a5: avcodec/imm4: Unreference previous frame on frame size change [20:46:33 CET] <cone-690> ffmpeg 03Carl Eugen Hoyos 07master:715186456c55: lavf/matroskaenc: Allow dvdsub remuxing from some containers. [00:00:00 CET] --- Mon Mar 11 2019

1 0

ffmpeg-devel.log.20190309
by burek 10 Mar '19

10 Mar '19

[10:29:29 CET] <sourabhboss> Hello ffmpeg - devel developers I will like to work on HEIF Support project during GSoC 2019 [10:29:55 CET] <sourabhboss> I have a required prequisites [10:32:06 CET] <durandal_1707> sourabhboss: contact mentor and you need to complete Qualification Task [10:32:45 CET] <sourabhboss> Sure durandal_1707 [10:33:55 CET] <sourabhboss> If someone already working on it Pls ping me [10:54:20 CET] <sourabhboss> Anyone know timezone of cehoyos [10:55:45 CET] <durandal_1707> sourabhboss: he is never on irc [10:56:02 CET] <durandal_1707> you can contact him only by mail [10:57:24 CET] <sourabhboss> Okay [16:33:23 CET] <cone-479> ffmpeg 03Andriy Gelman 07master:0a84ba26081c: avformat/mpegts: reduce buffering during initialization [16:33:23 CET] <cone-479> ffmpeg 03Michael Niedermayer 07master:f94b4f161151: avformat/mpegts: Simplify score compare [16:33:23 CET] <cone-479> ffmpeg 03Michael Niedermayer 07master:6e0b5d3a20e1: avcodec/dxv: Correct integer overflow in get_opcodes() [18:47:22 CET] <kierank> do we need a power9 fate? [18:51:31 CET] <jamrial> kierank: probably. there are some ppc64 fate clients, but i think those are power8 [18:51:54 CET] <kierank> I spoke to power9 people at SCALE they said it's easy for us to get a VM [18:52:21 CET] <jamrial> http://fate.ffmpeg.org/report.cgi?time=20190309154448&slot=ppc64le-linux-gc… looks like this one is power9 [18:52:26 CET] <jamrial> not sure who's "mik" [18:52:55 CET] <jamrial> but redundancy may be a good idea anyway [18:53:09 CET] <jamrial> and michaelni wanted more fate clients also testing release branches [19:43:24 CET] <cone-672> ffmpeg 03Kieran Kunhya 07master:2ff7af563a25: vf_showinfo: Fix timecode display [19:48:47 CET] <kierank> removing libndi [19:48:55 CET] <durandal_1707> what?!? [19:49:03 CET] <kierank> I said I would do that [19:49:10 CET] <durandal_1707> no consensus was reached [19:49:19 CET] <kierank> https://trac.ffmpeg.org/ticket/7589 [19:49:21 CET] <kierank> there is consensus [19:49:22 CET] <durandal_1707> you need to put it to ML [19:49:26 CET] <kierank> it already was [19:49:28 CET] <kierank> carl did it [19:49:30 CET] <durandal_1707> trac is not ML [19:49:35 CET] <kierank> https://patchwork.ffmpeg.org/patch/11263/ [19:50:32 CET] <durandal_1707> contact Carl before you gonna push your removal [19:51:19 CET] <kierank> done [19:52:01 CET] <j-b> +1 [20:49:19 CET] <cone-672> ffmpeg 03Martin Vignali 07master:26cf50404d1a: avcodec/proresenc_aw : fix interlace encoding for unsafe height [21:12:16 CET] <kierank> j-b: durandal_1707: see ml [21:15:15 CET] <JEEB> ayup [21:15:18 CET] <JEEB> they've gone silent [21:22:21 CET] <jamrial> kierank: don't remove the empty line in changelog [22:17:06 CET] <BtbN> They fixed the license violation, and were asked to release all their stuff under GPL. So yeah, I can totally see why they did not reply to that. [22:18:00 CET] <BtbN> Also, removing NDI require a major bump and deprecation period. [22:20:04 CET] <durandal_1707> BtbN: bullshit, that is not needed [22:20:13 CET] <BtbN> It's an ABI break [22:20:36 CET] <BtbN> Not in the classical sense, but programs will stop working without warning. [22:26:21 CET] <jamrial> we have removed wrappers without deprecation period before. all those external aac encoders, libdcadec, etc [22:26:52 CET] <jamrial> and i bet more people used libfaac than libndi [22:35:06 CET] <kierank> BtbN: they threaten open source developers with legal threats [22:35:20 CET] <kierank> why should we help them [22:35:50 CET] <BtbN> I still wasn't able to find anything about that. The only side of the story I know is from their perspective. [22:36:07 CET] <kierank> they threatened someone who implemented ndi indepdentetly [22:36:39 CET] <BtbN> Wasn't it about reverse engineering their library, which is against the license? [22:36:50 CET] <kierank> no [22:36:52 CET] <kierank> not in europe [22:36:56 CET] <kierank> those terms are meaningless [22:37:15 CET] <BtbN> Well, then you can probably just safely ignore any threaths. Github might kick you though, since US based. [22:37:23 CET] <kierank> ... [22:37:32 CET] <kierank> missing the point entirely [22:37:43 CET] <kierank> why should we support ndi in an open source project, when they threaten open source developers [22:37:58 CET] <BtbN> I'm more concerned about users than the company. [22:38:17 CET] <kierank> well users are compiling themselves [22:38:18 CET] <BtbN> Cause I know quite a lot of people who use NDI, and there is a distinct lack of alternatives. [22:38:20 CET] <kierank> so they can do what they want [22:38:28 CET] <BtbN> No, majority of them definitely is not. [22:38:35 CET] <kierank> then they are violating the gpl [22:38:39 CET] <kierank> so why should we care [22:38:46 CET] <BtbN> Yeah, why care about users. [22:38:55 CET] <kierank> yes why should we care about gpl violators [22:39:02 CET] <iive> if it is the same thing I think it is, then the proprietary version also has some known exploits. [22:40:05 CET] <kierank> newtek clearly are using ffmpeg to push their crappy blob [22:40:13 CET] <kierank> and attack people who want to remove the blob [22:42:19 CET] <kierank> we wouldn't accept it if it was dolby, microsoft etc [22:42:30 CET] <kierank> but because someone put it in and started using it doesn't make it right [22:56:29 CET] <iive> if there is an open source alternative to NDI, does ffmpeg support it? [22:56:32 CET] <iive> got any links? [00:00:00 CET] --- Sun Mar 10 2019

1 0

ffmpeg.log.20190309
by burek 10 Mar '19

10 Mar '19

[03:15:43 CET] <CyberShadow> Hello. What's the easiest way I can let a Windows user try a ffmpeg patch I made? [03:15:43 CET] <CyberShadow> I tried cross-compiling with the mingw-w64-* AUR packages, but that ends up in dependency hell for them (as they would need to get and unpack many of said packages). [03:44:01 CET] <ricemuffinball> what is better? vp9 or x265 [03:45:10 CET] <another> depends on your definition of better [03:46:14 CET] <pink_mist> x265 is an implementation of an encoder, while vp9 is coding format ... they're not even the same type of thing [03:58:08 CET] <ricemuffinball> okay how many vp9 encoders are out there [03:58:34 CET] <another> at least 2 [03:58:50 CET] <ricemuffinball> what is better? vp9 or h265 [03:58:57 CET] <ricemuffinball> pink_mist happy? [04:06:04 CET] <ricemuffinball> what is better? vp9 or h265 [04:06:28 CET] <ricemuffinball> or what is better x265 or vp9encoderthatgoogleuses [04:06:43 CET] <pink_mist> like another said, it depends on your definition of better [04:07:34 CET] <ricemuffinball> best quality/size [04:08:00 CET] <ricemuffinball> ignoring playback/hardware support [04:18:23 CET] <ricemuffinball> everybody: there is a program called "sox" that can trim the last 10/20/whatever seconds off of audio file" , if sox program can do this, why can't ffmpeg ? [04:21:26 CET] <kepstin> because it's a different program that works in a different way and was made by different people, none of whom wrote that functionality. [04:22:58 CET] <kepstin> (if someone was going to write that feature, the way to do it would be to add a "-toeof" input option, analogous to -sseof) [04:23:41 CET] <ricemuffinball> is that difficult to do? [04:24:34 CET] <ricemuffinball> sox "R:\1.flac" "R:\2.flac" trim 0 -20 [04:24:41 CET] <kepstin> Probably not that hard? But it's C code, so lots of fun ways to screw it up. [04:24:59 CET] <ricemuffinball> kepstin are you saying "C" is horrible code language? [04:25:36 CET] <kepstin> i'm kinda surprised that -sseof got added, tbh, we used to just tell people "use ffprobe to see how long the file is and calculate the start time yourself" [04:26:42 CET] <kepstin> but i guess someone finally got fed up enough with that answer that they decided to write the option :) [04:26:58 CET] <ricemuffinball> what is the point of -sseof if i cannot even use trim command [04:30:50 CET] <ricemuffinball> kepstin do you even know the point of having -sseof option [04:31:11 CET] <kepstin> to let you set a start point relative to the end of the time [04:31:22 CET] <kepstin> useful for anyone doing the opposite of what you want to do. [04:31:48 CET] <ricemuffinball> so only include the last 30 seconds of the file [04:34:41 CET] <Hello71> wait, are values not allowed to start with -? [04:35:46 CET] <another> no [04:35:57 CET] <another> at least not for -t [04:37:03 CET] <kepstin> note that -sseof takes negative values as input [04:37:04 CET] <kepstin> it's a separate option because timestamps are weird, and there's some weird cases when you might legit want to seek in a negative direction relative to the start of the file. [04:37:42 CET] <kepstin> (-t is duration, and negative duration makes no sense) [04:39:19 CET] <kepstin> -to is used to set a stop time, but it has the same issue as -ss where a negative offset from the start of the file is possible (really unusual, but yeah) [04:42:16 CET] <ncouloute> test [04:42:37 CET] <kepstin> ncouloute: didn't work, so sorry about that. [04:46:06 CET] <analogical> why hasn't this been updated with 4.1.1 ?? https://ffmpeg.org/index.html#news [04:47:07 CET] <ricemuffinball> analogical wow you are right [04:47:20 CET] <ricemuffinball> wow, what a mess up [04:48:17 CET] <ncouloute> Is there any way for ffmpeg to tell you what frame 50 in the input file is in the output file. If I changed the fps. (In my head there is a hard way) If not then is there a way to strictly duplicate every frame? [04:48:46 CET] <ricemuffinball> ncouloute what are you trying to do exactly? [04:52:24 CET] <another> unfortunately ffmpeg doesn't do news posts for patch releases [04:53:27 CET] <ncouloute> So I got a file that is 29.97 fps (roughly) and I am converting it to 59.94 fps. I have a set of marks based on the frame number. So Mark in/Mark Out. I want to maintain those marks I tried just doubling the frame number but i ended up being off by a few frames. My guess is has to do with the original file not being exactly 29.97. MediaInfo reports Variable FPS between 29.97 and 30 on the origanl file. [04:53:51 CET] <kepstin> analogical: there's never any new features in the point releases, so just assume it says "Bug fixes and performance improvements" or something. [04:54:00 CET] <kepstin> although there's usually not any performance improvements either [04:54:29 CET] <furq> ncouloute: are you converting to 59.94fps or 60000/1001 fps [04:56:20 CET] <ncouloute> using "-vf fps=60000/1001" [04:57:44 CET] <ncouloute> My thought is if I can just double every frame. I would get a file close to 60 fps but ideally I can figure out what frame ffmpeg will change it to [05:16:24 CET] <analogical> kepstin, I noticed a slight performance increase but only do simple stuff :) [05:58:26 CET] <ricemuffinball> is h264 the first codec to support HD video? [06:00:06 CET] <another> certainly not [06:01:04 CET] <ricemuffinball> huh, then what [06:01:32 CET] <another> well there have been quite a few codecs before h264 [06:01:48 CET] <ricemuffinball> such as [06:02:05 CET] <another> mpeg{1,2,4} [06:02:25 CET] <another> among others [06:03:01 CET] <ricemuffinball> mpeg1 doesn't support HD [06:03:33 CET] <furq> Stream #0:0: Video: mpeg1video, yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc [06:03:36 CET] <furq> sure it does [06:04:57 CET] <furq> if you mean things that were actually used for hd then MUSE is probably the first [06:05:05 CET] <furq> unless you can think of something earlier than 1979 [06:06:18 CET] <another> mpeg2 is still quite popular in broadcasting afaik [06:06:27 CET] <another> even for HD content [08:50:05 CET] <ricemuffinball> should i use "costant frame rate" or "variable frame rate" [09:21:43 CET] <Ariyasu> you probably want cfr [09:22:02 CET] <Ariyasu> theres pretty much no reason you would ever want vfr [09:59:20 CET] <ricemuffinball> Use VFR - Variable Frame Rate (Recommended) [09:59:20 CET] <ricemuffinball> VFR is a very efficient recording method which allows you to get small file sizes with the maximum FPS which the recording target can obtain. For example, even though you select "60" FPS at the video settings, you will get a "variable 40FPS video" if you are able to get only 40FPS while recording. [14:47:29 CET] <dongs> hi, how can i take some 4K60P ts/mpeg file and split it into .hevc file frame by frame [14:47:41 CET] <dongs> actually split frame, not reencode or save as png or wahtever [14:47:49 CET] <dongs> but just dump each raw .hevc into frame [14:49:29 CET] <JEEB> the splitting part gets more funky, but dumping the raw Annex B with the start codes should be quite possible from stuff like MPEG-TS [14:49:44 CET] <dongs> i'd rather not code it [14:49:56 CET] <dongs> i'd rather just type in some mile-long command line for ffmpeg [14:50:07 CET] <dongs> i don't expect it to be playable, im jsut curious waht the frame sizes should be,. [14:50:29 CET] <dongs> the mmt stuff im fucking with, im getting one mpu in teh few megs size, and I doubt thats how big a single frame is, even if its an i-frame [14:50:29 CET] <JEEB> hmm, in that case if it's MPEG-TS you might get around by just indexing with DVB Inspector or so [14:50:33 CET] <JEEB> it shows the PES packet sizes [14:51:21 CET] <JEEB> or if you just want to figure out how much between each start code (four or three byte 0x00 00 00 01 IIRC) [14:51:32 CET] <dongs> yeah i guess that works too [14:51:35 CET] <JEEB> ffmpeg -i in.ts -c copy -map 0:v:0 out.h264 [14:51:41 CET] <JEEB> uhh not h264 [14:51:44 CET] <dongs> hevc [14:51:46 CET] <dongs> but yea [14:51:47 CET] <JEEB> .hevc, yea [14:51:51 CET] <dongs> lets try [14:52:11 CET] <JEEB> if you know the pid you can do -map "0#0xblah" too instead of "first video track from first input" [14:52:26 CET] <JEEB> anyways, I should take a further look at your MMT stuff [14:52:33 CET] <JEEB> would be interesting how much IP bullshit one has to parse [14:52:45 CET] <JEEB> as in, do you really have to implement IP packet parsing up to the media level [14:52:50 CET] <dongs> no [14:52:52 CET] <dongs> there's no IP [14:53:01 CET] <dongs> the onyl IP shit there is NTP [14:53:03 CET] <dongs> in each slot start [14:53:06 CET] <dongs> but you can ignore that [14:53:12 CET] <dongs> the rest of teh stuff is HCfB [14:53:16 CET] <dongs> which strips all teh ip packets [14:53:16 CET] <JEEB> ok [14:53:25 CET] <JEEB> that's much better than I expected [14:53:28 CET] <dongs> er ip packets = IP HEADERS [14:53:33 CET] <JEEB> yea [14:53:41 CET] <JEEB> you have the IP over broadcast thing and just the data I guess? [14:53:51 CET] <JEEB> with the headers being in the IP over broadcast packets [14:54:06 CET] <JEEB> (I don't remember the exact ITU spec name, sorry) [14:54:33 CET] <dongs> http://bcas.tv/paste/results/BYvBA529.html some work in progress here to just walk through the structures [14:54:33 CET] <JEEB> also if this crap really has MPEG-H audio that'd literally be the first example of me seeing it in the real world [14:54:57 CET] <JEEB> :) [14:55:24 CET] <JEEB> I remember you linking a thing the day before, I might grab a sample or so from there [14:55:40 CET] <dongs> i did record the 22.2 stuff but since thats crypted i don't wanna fuck wiht it until im sure the mpu packet ordering stuff works [14:55:47 CET] <JEEB> aye [14:56:07 CET] <dongs> decrpytion works (at least for audio), but the CID stuff is fucking up video [15:00:27 CET] <match_it> hi all. I have a server with video files (vod). I would to test (as simulation I mean) if 10 or 100 users connect for watching. Is there a tool for this pourpose ? [15:00:31 CET] <dongs> https://i.imgur.com/myYQhab.png TR-B39 part4 only mentions this about CID [15:00:53 CET] <dongs> currently dumping all MPU sorted by cid/sequence number/mpu sequence number [15:01:01 CET] <dongs> and seeing if something makes sense [15:02:29 CET] <JEEB> right, so it's the IP data flow identifier, and then you just have teh +1 number [15:03:13 CET] <dongs> https://i.imgur.com/0J98fht.png [15:03:21 CET] <dongs> -1- -2- is CID [15:03:24 CET] <dongs> A001 is PID [15:03:38 CET] <dongs> so there's shit mixed and i have no idea how/why [15:04:57 CET] <dongs> if I make counters for all packets belonging to different CIDs [15:05:13 CET] <dongs> 0x0125b368 {0, 536, 29596, 371, 1093, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0} [15:05:19 CET] <dongs> the spread is something liek this for a few 100megs sample [15:05:29 CET] <dongs> cid1 = 536, cid2 = 29xxx etc [15:06:08 CET] <JEEB> match_it: most companies make their own based on some load testing framework. that might or might not contain FFmpeg :P [15:06:20 CET] <JEEB> (I mean, you don't really need to play or process the data to load test) [15:08:29 CET] <match_it> thanks JEEB, could you go indeep a bit on how they actually do ? [15:08:39 CET] <match_it> could you say something more ? [15:08:41 CET] <JEEB> dongs: not knowing the packet sizes the 29596 one looks like it's pushed a lot of stuff through [15:08:56 CET] <dongs> packet size = ~0x550 avg [15:09:02 CET] <dongs> (thats tlv packet size) [15:09:08 CET] <dongs> they're variable-ish but around there. [15:09:11 CET] <JEEB> aye [15:09:19 CET] <dongs> anyway, i just ran it for liek 4 seconds and breakppointe and looked at counts. [15:09:20 CET] <JEEB> since finally they made variable packet sizes with TLV :P [15:10:35 CET] <JEEB> match_it: basics are to emulate a player in the parts that actually access the servers. there's multiple load testing frameworks (some in java, some in python) :P [15:11:49 CET] <JEEB> match_it: you can f.ex. just search for "github HLS load test" for example [15:12:07 CET] <match_it> my main conerns is where the players are loaded ? I would to understand if infrastructure layer is suitable (reliable) to give me what the promise .... :P [15:12:55 CET] <match_it> basically I would test if my ISP gives me enough bandwidth [15:13:06 CET] <match_it> (instant bandwidth) [15:13:52 CET] <dongs> JEEB: hmm, lots of 0001's at start of frame to setup decoder i guess [15:14:10 CET] <dongs> and then 1st next frame is 0x3700 offset away [15:14:12 CET] <dongs> okay makes sense [15:14:39 CET] <JEEB> I thought they went all out with ISOBMFF which should have lengths and not Annex B, but ok :D [15:14:52 CET] <dongs> no this is from 4k mpegts from skapa [15:14:56 CET] <JEEB> ISOBMFF has length+data, while annex b is start code+data [15:14:58 CET] <JEEB> ah [15:15:03 CET] <dongs> using your ffmpeg line [15:15:06 CET] <JEEB> right'o [15:15:08 CET] <dongs> just checking sditances between packets [15:15:28 CET] <JEEB> also you can utilize the dump headers or whatever it was bit stream filter [15:15:33 CET] <JEEB> if you need to look further [15:15:46 CET] <dongs> ctrlf in hex editor works fine [15:15:50 CET] <JEEB> but just looking at start codes often gives a basic idea [15:15:51 CET] <JEEB> yea [15:25:25 CET] <match_it> thanks JEEB, I'm looking for load test as you said [15:29:00 CET] <ossifrage> Any ideas how to convince ./configure to only build libavformat, --disable-all --enable-avformat just results in avutil being built [15:32:02 CET] <JEEB> you'd probably want to enable some muxers/demuxers/protocols? and yes, that sounds weird given you'd think you'd want all (although that would also bring parsers etc from lavc) [15:32:32 CET] <JEEB> might also want to open a ticket on trac to document the current behavior and if it's considered weird improving it [15:32:55 CET] <ossifrage> JEEB, I've been trying from the other direction and it seems to result in avformat not getting built [15:34:08 CET] <ossifrage> (ah, getting closer, it still builds a huge pile of stuff, I guess I should punt and figure out exactly what I need) [15:38:20 CET] <ossifrage> JEEB, yeah it seems that avformat is getting turned off, not sure what is triggering it [15:40:58 CET] <ossifrage> I just punted and let buildroot build whatever it wanted, I'm still using a nfs root, so I can afford some bloat for the time being [15:42:35 CET] <JEEB> ossifrage: still that sounds like there's two levels of flags, and if there's been a full disablement on one level, even if you enable the lib on the same level if the features are not enabled that you require, then it gets funky :P [15:42:45 CET] <JEEB> which is why I think an issue on trac might be worthwhile [15:43:08 CET] <ossifrage> Trying to multiplex some live h.264 elementary steams (from a hardware encoder) into something chrome will play [15:43:46 CET] <ossifrage> JEEB, yeah the --disable flags turn things off that prevent other things being turned on (or somesuch) [15:44:16 CET] <JEEB> I've seen other things do --disable-encoders --enable-encoder=list,of,things [15:44:26 CET] <JEEB> or muxers/protocols/etc [15:45:20 CET] <ossifrage> FFMPEG_CONF_OPTS += --disable-encoders $(foreach x,$(call qstrip,$(BR2_PACKAGE_FFMPEG_ENCODERS)),--enable-encoder=$(x)) [15:45:38 CET] <ossifrage> That is what buildroot does... disable everything and then enable what you want [17:22:44 CET] <Accord> I need to efficiently add some video effects on subsegment of a h264 video file, what's the best way to cut that subsegment without transcoding and make sure that I can reinsert it back in the original video? [17:23:36 CET] <Accord> I created the original h264 file so concat compatibility is not a problem, I can use the same transcoding options on the new segment and concat the before and after pieces [17:26:05 CET] <JEEB> if you are using libx264 there's an option you can pass to it through libx264-params "stitchable=1" that keeps the parameter sets completely the same (there's some optimization that x264 does to make them smaller by default) [17:26:26 CET] <JEEB> then otherwise it's a case of you indexing a video and figuring out where you have to start decoding and re-encoding [17:26:33 CET] <JEEB> and then stitching the AVPackets together [17:44:18 CET] <Accord> JEEB: any way to do this just with the CLI tool? [17:45:32 CET] <JEEB> in a very limited sense of having to still index the bloody thing and using a container where seeking works exactly. not to mention that the stiching up is much less comfy than you'd think [17:46:58 CET] <Accord> JEEB: so use mkv instead of mp4 and ffprobe to know exactly at which frame numbers to cut? [17:47:46 CET] <JEEB> both mp4 and matroska are fine, and you'd have to do stuff with ffprobe yes [17:48:36 CET] <Accord> thanks [18:33:38 CET] <pripolo> Hello I have a SVHS VCR plugged into the S-Video port on a Hauppauge WinTV-HVR1-800, when I try to record video all I get is black output, even when playing a tape [18:34:22 CET] <pripolo> Here is the command and output, and firmware driver loading (CX23885) https://0x0.st/zHaF.txt [18:34:58 CET] <JEEB> pripolo: that "not initialized or corrupted" thing sounds bad in the dmesg [18:35:10 CET] <pripolo> no that's normal [18:35:23 CET] <JEEB> ok, does anything else read the video through v4l2? [18:35:35 CET] <JEEB> also it seems to enable two video devices [18:35:35 CET] <pripolo> what else can I test with? This is on a headless system [18:35:39 CET] <JEEB> video0 and video1 [18:35:48 CET] <pripolo> video0 is v4l2, video 1 is MPEG2 for TV [18:36:21 CET] <JEEB> with headless it's much less simple but you could check if vlc had a v4l2 module [18:36:42 CET] <pripolo> trying video1: [video4linux2,v4l2 @ 0x6516c40] Cannot find a proper format for codec 'none' (id 0), pixel format 'none' (id -1) [18:36:44 CET] <pripolo> ok [18:36:58 CET] <pripolo> https://wiki.videolan.org/Documentation:Modules/v4l2/ [18:41:25 CET] <pripolo> there is no CLI only VLC [18:47:25 CET] <JEEB> pripolo: there most definitely is [18:47:38 CET] <pripolo> i mean I have to install 100 extra packages i do not need [18:47:39 CET] <JEEB> you just need to run it without an interface defined [18:47:41 CET] <JEEB> right [18:47:50 CET] <JEEB> then you have to build it without the Qt etc interfaces :P [18:47:56 CET] <JEEB> (or see if there's a more limited package) [18:47:59 CET] <pripolo> oh yes I can build from source I guess [18:48:06 CET] <pripolo> this is linux after all [18:48:15 CET] <JEEB> I think some distributions provide more limited vlc packages [18:48:26 CET] <pripolo> i use debian [18:51:26 CET] <pripolo> oh [18:51:35 CET] <pripolo> with mencoder [18:51:37 CET] <pripolo> inputs: 0 = Television; 1 = Composite1; 2 = S-Video; [18:53:32 CET] <pripolo> mencoder tv:// -v -tv driver=v4l2:width=720:height=480:input=2:device=/dev/video0 -ovc copy -o raw.avi [19:00:36 CET] <pripolo> JEEB I got it [19:00:57 CET] <pripolo> mencoder tv:// -v -tv channel=0:driver=v4l2:device=/dev/video0:input=2:width=720:height=480 -ovc copy -nosound -o out.avi [19:01:01 CET] <pripolo> this is not with ffmpeg though so [19:01:17 CET] <JEEB> so you have to pick the input from a specific device [19:01:18 CET] <JEEB> I guess [19:01:59 CET] <pripolo> yeah [19:02:05 CET] <pripolo> now to get it with ffmpeg [19:02:08 CET] <pripolo> so that I can use huffyuv [19:02:12 CET] <JEEB> ffmpeg -h demuxer=v4l2 [19:02:20 CET] <JEEB> see if any of those options are of use [19:02:26 CET] <JEEB> possibly the list_x ones [19:03:08 CET] <JEEB> also raise the verbosity level to debug with -v debug since I see a lot of messages in the module with that level [19:12:18 CET] <pripolo> uhm [19:12:20 CET] <pripolo> so [19:12:28 CET] <pripolo> JEEB after installing mencoder, ffmpeg works [19:12:36 CET] <pripolo> so I think it was actually I was missing some libraries... [19:12:41 CET] <JEEB> lol [19:13:00 CET] <pripolo> I don't like libraries [19:13:12 CET] <pripolo> makes a mess. I prefer static [19:13:57 CET] <durandal_1707> dont use mencoder [19:14:21 CET] <pripolo> no I don't want to, it was just a test. ffmpeg is better because i can use huffyuv [19:15:33 CET] <pripolo> now im trying to figure out audio [19:16:23 CET] <pripolo> Hardware PCM card 1 'Conexant CX23885' device 0 subdevice 0 [19:33:09 CET] <pripolo> JEEB, now I am stuck on audio [19:37:18 CET] <pripolo> https://0x0.st/zHM-.txt [19:37:24 CET] <pripolo> some outputs I get [20:12:44 CET] <pripolo> do I need an ffmpeg with --enable-indev=alsa --enable-outdev=alsa ? [20:12:50 CET] <pripolo> because I can see alsa when i do ffmpeg -formats [20:19:46 CET] <JEEB> pripolo: the alsa indev most definitely seems to be there? [20:19:58 CET] <pripolo> how do I for sure check? [20:20:05 CET] <pripolo> -formats or configuration output? [20:20:11 CET] <JEEB> -demuxers [20:20:30 CET] <JEEB> ffmpeg -demuxers |grep alsa [20:20:42 CET] <pripolo> D alsa ALSA audio input [20:20:45 CET] <JEEB> anyways, you wouldn't get those messages there otherwise [20:20:49 CET] <JEEB> they're specifically labeled alsa [20:21:01 CET] <pripolo> it's there. im just confused why mencoder would work with audio output but not ffmpeg [20:21:02 CET] <JEEB> so there is code built which is a) input b) called alsa [20:21:24 CET] <JEEB> probably just naming differences etc [20:21:59 CET] <JEEB> you define hw:1 and it attempts to open hw:1,1 and hw:1,2 just looking at your posted part of the log :P [20:22:11 CET] <pripolo> yeah that was me just trying other subdevices [20:22:21 CET] <pripolo> 1,1 and 1,2 fails, but 1,0 is OK, just no actual audio captured [20:22:39 CET] <JEEB> bump verbosity, check stuff [20:22:42 CET] <JEEB> -v debug [20:28:20 CET] <pripolo> JEEB https://0x0.st/zHM9.log [20:28:27 CET] <pripolo> ffmpeg output [20:30:27 CET] <JEEB> can you check what sort of audio sample rate and channel count mencoder is taking out of the alsa device (and that it is using the same alsa device) [20:30:56 CET] <pripolo> yup [20:31:13 CET] <pripolo> https://0x0.st/zHMV.txt full mencoder log [20:31:34 CET] <pripolo> AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000) [20:32:49 CET] <JEEB> also main thing [20:32:54 CET] <JEEB> it's using v4l2 for the audio, too [20:33:06 CET] <JEEB> or whatever the tv:// thing is doing in mencoder [20:33:08 CET] <pripolo> oh darn [20:33:12 CET] <JEEB> the logging at least goes under v4l2 [20:34:04 CET] <JEEB> I don't have the mencoder code at hand to tell you if it just uses alsa or not in the background [20:34:16 CET] <JEEB> or if the v4l2 interface also has audio input [20:34:54 CET] <pripolo> I can't use -f v4l2 anyway because it wants video [20:34:56 CET] <pripolo> for audio i mean [20:36:14 CET] <pripolo> wait I think I got it [20:36:36 CET] <JEEB> I was specifically talking of mencoder there since the audio seems to be coming from underneath it, too :P [20:39:40 CET] <pripolo> alright well I'm very confused... but now there's audio [20:39:45 CET] <pripolo> and it's unrelated to watching TV at the same time [20:39:55 CET] <pripolo> I thought maybe someone was watching [20:39:57 CET] <pripolo> but now it works? [20:40:48 CET] <pripolo> ffmpeg -f v4l2 -thread_queue_size 2048 -video_size 720x480 -i /dev/video0 -f alsa -thread_queue_size 2048 -i hw:1 -c:v huffyuv -c:a pcm_s16le -t 15s "$(date +%s)".avi [20:50:49 CET] <pripolo> and now it's not working again... wtf [21:18:30 CET] <pripolo> yeah I don't get it JEEb. I've tried it all [21:18:32 CET] <pripolo> doesn't work [21:34:06 CET] <ossifrage> Anyone know of an libavformat example that multiplexes live streams? [21:34:32 CET] <JEEB> I don't think there's anything special with that? [21:34:37 CET] <JEEB> what exactly do you mean? [21:35:08 CET] <ossifrage> How about something better then: https://ffmpeg.org/doxygen/0.6/output-example_8c-source.html [21:35:29 CET] <JEEB> when searching for FFmpeg doxygen, look for trunk [21:35:35 CET] <JEEB> esp. not branches that are really, really old [21:35:37 CET] <JEEB> (like 0.6) [21:35:49 CET] <JEEB> https://roundup.ffmpeg.org/doxygen/trunk/transcoding_8c-example.html [21:35:53 CET] <JEEB> I think this is the most updated example [21:35:59 CET] <ossifrage> JEEB, yeah that was the first hit from elgoog [21:36:07 CET] <JEEB> it handles a lot of stuff, but you can grasp out of it the parts that you need just for parts of it [21:36:17 CET] <JEEB> like the input/output AVFormatContexts etc [21:36:49 CET] <ossifrage> I've used ffmpeg to encode video, but that was a long time ago and I'm really rusty with how it works [21:37:06 CET] <JEEB> for the decoding and encoding APIs we have a separate thing that documents that pretty wel [21:37:09 CET] <JEEB> *well [21:37:13 CET] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [21:37:23 CET] <JEEB> not perfect, but I think that's pretty good :P [21:37:39 CET] <ossifrage> JEEB, I remember it going pretty quick [21:39:23 CET] <ossifrage> It has been a long time since I did any multiplex and that was bloody transport streams, ick [21:41:09 CET] <dkozel> Hello. I'm trying to create a constant bitrate transport stream from a webcam and microphone and seem to have it 90+% working, but the audio loses sync intermittently [21:41:13 CET] <dkozel> https://pastebin.com/BtgigrRs [21:41:29 CET] <dkozel> I'm capturing with ffmpeg and playing back with mplayer [21:41:39 CET] <ossifrage> I have the encoded frames with NALU boundaries and the pts [21:42:06 CET] <dkozel> the ffmpeg command is: [21:42:08 CET] <dkozel> ffmpeg -f alsa -thread_queue_size 2048 -i hw:2 -f v4l2 -thread_queue_size 2048 -video_size 1920x1080 -input_format h264 -framerate 24 -r 24 -i /dev/video2 -c:v libx264 -b:v 16M -maxrate 15M -bufsize 8M -b:a 128k -c:a aac -muxrate 17413400 "$(date +%s).ts" [21:42:37 CET] <pripolo> JEEB I'm giving up for now on audio [21:42:46 CET] <ossifrage> dkozel, you can always pad transport streams up to any rate you want but injecting null packets [21:43:08 CET] <dkozel> I believe that that's what muxrate does? [21:43:12 CET] <JEEB> yes [21:43:26 CET] <JEEB> you can verify the result with something like DVB Inspector, I think [21:43:29 CET] <dkozel> and I have a tool that shoes that works [21:44:02 CET] <dkozel> here: https://github.com/drmpeg/dtv-utils/blob/master/xport.c [21:45:17 CET] <dkozel> Oh [21:45:30 CET] <dkozel> mplayer thinks the TS is at 48 fps, not 24 [21:45:37 CET] <dkozel> let me override that and see if it syncs [21:46:09 CET] <JEEB> I would generally test with ffprobe, vlc and mpv or so (two FFmpeg-using and one that doesn't utilize FFmpeg for demux) [21:46:11 CET] <dkozel> And no, I've already overridden it in the pastbin [21:46:23 CET] <dkozel> ok, I can give those a try [21:46:35 CET] <JEEB> ffprobe -show_packets shows the timestamps of the packets [21:46:48 CET] <JEEB> you could do similar checks with DVB Inspector for all PES packets [21:47:01 CET] <JEEB> (it's an MPEG-TS analyzer, will show you DTS/PTS fields) [21:47:30 CET] <dkozel> VLC has the same audio glitch [21:48:38 CET] <dkozel> I'll check out DVB inspector [21:48:38 CET] <JEEB> check the timestamps, then start checking stuff like -debug_ts in ffmpeg.c to see what sort of video/audio timestamps are being passed through [21:48:55 CET] <JEEB> it will log a *lot* but you will see each packet through its life cycle [21:49:02 CET] <pripolo> JEEB alright I think I got it... I had installed libraries from debian repo for mencoder, so I think the static build was using THOSE instead of the static libraries [21:49:04 CET] <pripolo> cause now it works [21:49:09 CET] <pripolo> after removing mencoder and all extra packages [21:49:28 CET] <pripolo> sorry for interrupt I just needed to mention [21:52:13 CET] <dkozel> OK, the audio drop out is very visible in DVB Inspector [21:52:40 CET] <JEEB> -debug_ts time, just be prepared for like four-to-five lines for each packet [21:52:44 CET] <dkozel> the Audio with ADTS transport syntax PTS nodes just stop cose to the end of the file [21:53:59 CET] <dkozel> Hmm. I wonder if this is some issue with the muxrate and the video rate I've chosen [21:54:35 CET] <dkozel> the audio drop is immediately at the first point where the video bitrate clips into the muxrate [21:55:16 CET] <dkozel> How do I run the debug_ts on file? [21:55:41 CET] <dkozel> I'm far from a video expert, heh, this is definitely a learning experience [21:56:20 CET] <JEEB> it's a parameter for ffmpeg.c [21:56:28 CET] <JEEB> and you do it while testing the encoding :P [21:56:46 CET] <JEEB> also bolster your verbosity level to at least -v verbose [21:57:11 CET] <JEEB> (it's not as spammy as -v debug, but still gives you some extra info on what ffmpeg.c or FFmpeg's libraries are doing) [21:57:16 CET] <dkozel> ok [22:04:02 CET] <dkozel> It's going to take a while to interpret the output, but looking in DVB inspector (and just watching the files) the error is always at the end of the file [22:04:13 CET] <dkozel> Audio does not recover once it's dropped [22:09:30 CET] <dkozel> Hmm. interesting correlation. The AAC audio reports an FPS of 31.25. The video is 24 FPS. that's a ratio of 1.302. The ratio of video duration to sound duration is 1.269 [22:09:57 CET] <dkozel> The audio and video are synchronized, but maybe the audio is being trimmed inappropriately [22:23:10 CET] <pripolo> that is normal for audio I see it often [22:23:24 CET] <pripolo> if you are reading mediainfo [22:25:36 CET] <dkozel> I am [22:26:24 CET] <dkozel> reading through the ts_debug log, I'm not making much sense of it. [22:27:10 CET] <dkozel> there's a possible discrepancy where the video pts time is ahead of the audio ones near it in the log [22:27:23 CET] <dkozel> I'm going to try recapturing without the -r option [22:27:52 CET] <dkozel> I added that to resolve "Past duration 0.xxxxx too large" errors [22:28:02 CET] <dkozel> but maybe it's just hiding the actual problem [22:29:37 CET] <dkozel> at least the problem is 100% reproducible, and no, removing -r didn't solve it [22:35:05 CET] <furq> dkozel: 31.25fps is normal for 32khz audio [22:35:13 CET] <dkozel> thanks furq [22:35:22 CET] <furq> idk why mediainfo even bothers to report it like that [22:35:46 CET] <dkozel> *shrug* [22:36:11 CET] <dkozel> It's probably a true fact in someway, even if a bit confusing [22:36:24 CET] <furq> it is technically true [22:36:46 CET] <furq> aac is usually 1024 samples per frame, so 1024 * 31.25 = 32000 samples per second [22:36:58 CET] <furq> i just don't know why you'd ever need to know that expressed in fps [22:37:03 CET] <dkozel> Ah. Yeah, that makes sense then [22:37:24 CET] <dkozel> Actually, I think I have a case [22:37:40 CET] <dkozel> a radio system I work with has configurable packets per second [22:38:04 CET] <dkozel> knowing the frame rate of encoded audio would be nice working with that [22:38:18 CET] <dkozel> https://pastebin.com/4e4uYTfH [22:38:53 CET] <dkozel> I realize asking for someone to read a verbose log is a stretch, but I think I've reached my current understanding and am not sure what to take from this [22:39:16 CET] <dkozel> On this recording the last audio PTS is at ~0.431 seconds [22:39:27 CET] <dkozel> in the outputted ts [00:00:00 CET] --- Sun Mar 10 2019

1 0

ffmpeg-devel.log.20190308
by burek 09 Mar '19

09 Mar '19

[02:38:53 CET] <cone-558> ffmpeg 03Jun Zhao 07master:26dbe88ea37b: lavfi/zscale: make use of AVFILTER_DEFINE_CLASS [02:38:53 CET] <cone-558> ffmpeg 03Jun Zhao 07master:96451477b911: lavfi/tonemap: make use of AVFILTER_DEFINE_CLASS [15:28:09 CET] <cone-862> ffmpeg 03Linjie Fu 07master:147ef1d9472e: lavf/deinterlace_qsv: set specific field for repeat [15:28:12 CET] <amaim_> Hello there, is there anywhere I can learn more about muxers and demuxers? any documents to study or source? and another thing what code convention/style do we use in ffmpeg? [15:32:33 CET] <thardin> amaim_: I believe the code style is in the documentation [15:32:45 CET] <thardin> there's also a new codec/format checklist in there [15:33:09 CET] <thardin> simplest is to just follow the style that's already in place [15:47:22 CET] <atomnuker> when is dav1d 1.0 happening? [15:48:36 CET] <nevcairiel> when its done(tm) [15:49:38 CET] <jamrial> probably not until 10bit has at least about the same coverage 8bit has today, i'd say [15:52:20 CET] <atomnuker> forgot about 10 bit [15:53:24 CET] <atomnuker> wish youtube would start using it for 720p+ already but not even they can yet [15:53:56 CET] <nevcairiel> there is select videos with 720p encodes [15:54:24 CET] <nevcairiel> but they are probably also not in a hurry yet until faster decoders roll out everywhere [15:55:15 CET] <jamrial> at first they made 720p and 1080p encodes for all videos, but then stopped and even removed those already made [15:56:03 CET] <jamrial> too slow to encode, to slow to decode at the time as well, and most users probably at most enabled then "up to 480" testtube option anyway [15:56:48 CET] <nevcairiel> .. which would never even engage for me since all videos played are just higher res [15:58:38 CET] <atomnuker> dav1d is very fast at 8 bit stuff, so I think its mostly just encoders [15:59:04 CET] <atomnuker> libvpx must have been just enough for them to handle [20:32:32 CET] <durandal_1707> i got ASPX almost working, but how this thing is properly scaled? [00:00:00 CET] --- Sat Mar 9 2019

1 0

ffmpeg.log.20190308
by burek 09 Mar '19

09 Mar '19

[01:37:26 CET] <ricemuffinball> what is more noticable to human eye? 4:2:0 vs 4:4:4 or 8bit color vs 10bit color [01:57:42 CET] <c3r1c3-Win> I would say it depends on the content. [01:57:53 CET] <c3r1c3-Win> And the display the person is viewing it on. [01:58:15 CET] <c3r1c3-Win> And how the person views/weights things. [02:00:19 CET] <ricemuffinball> picture of a human [02:00:53 CET] <ricemuffinball> on a 10 bit color monitor [02:01:39 CET] <ricemuffinball> c3r1c3-Lin there [02:03:07 CET] <ricemuffinball> .red [02:03:51 CET] <c3r1c3-Win> Hmm...then it would depend on the brightness of said monitor. If it's say... 1,000 nits+ that would weigh in favor of the 10-bit [02:04:26 CET] <c3r1c3-Win> BUT if it's a still then the 420 will be noticeable than if it's video, esp. video with a lot of motion. [02:04:38 CET] <c3r1c3-Win> *be MOR noticeable [02:04:42 CET] <c3r1c3-Win> **MORE [02:04:59 CET] <ricemuffinball> okay, what if it's video not a still "or human being" [02:05:01 CET] <ricemuffinball> of* [02:05:25 CET] <pink_mist> (why not both, though?) [02:05:38 CET] <pink_mist> 4:4:4 10bit [02:06:00 CET] <ricemuffinball> pink_mist because that's not my question [02:20:08 CET] <c3r1c3-Win> In general I would go for the 10-bit stuff, esp. on a 'true' HDR display. [02:20:58 CET] <Sauraus> Hello [02:21:31 CET] <Sauraus> Can anyone tell how I can suppress messages like these [hls,applehttp @ 0x19f6fc0] [02:21:44 CET] <c3r1c3-Win> It not only expands the luminance range, but also the color range as well, and since 420 is fairly pervasive (and most people don't notice it that much) I think that the extra contrast/brightness/nuance would be better appreciated. [02:22:47 CET] <c3r1c3-Win> BUT...if one has lots of solid colors in a limited range, then 444 will "win" because you're content is playing to it's strength. [02:23:04 CET] <c3r1c3-Win> *solid=solid/bold [02:38:41 CET] <ricemuffinball> every video i have seems to use: Color space: --------> YUV . is it possible to have a video file use other than YUV ? [02:39:26 CET] <pzy> YUV is a color encoding system, so it can also be RGB [02:40:21 CET] <ricemuffinball> pzy why is it that i never acrossed a video file that use RGB then [02:41:22 CET] <pzy> beats me! you could convert it to RGB with ffmpeg though probably haha [02:41:45 CET] <ricemuffinball> okay let me try: how do i do that [02:42:08 CET] <pzy> -pix_fmt rgb24 [02:44:14 CET] <ricemuffinball> pzy is YUV and rGB are only "color space" options out there [02:45:17 CET] <pzy> I'm not really an expert on that, but yeah I think it's just those two, with some modifications for HD video and such [02:46:09 CET] <pink_mist> try ffmpeg -pix_fmts [02:46:16 CET] <pink_mist> for me it lists loads of others [02:46:53 CET] <pzy> pixel formats are different than color space [02:46:56 CET] <pzy> but also similar [02:47:02 CET] <pink_mist> oh [02:47:07 CET] <pzy> it's all very complicated and you can blame 1960s TV engineers [02:48:05 CET] <iive> yuv is more efficient for encoding video, because human eye is more sensitive to light, than color [02:48:33 CET] <pzy> and it originally had something to do with getting a coherent black and white picture out of the single Y signal [02:48:41 CET] <pzy> rather than RGB which wouldn't look great in a single channel [02:48:55 CET] <ricemuffinball> -pix_fmt rgb24 resulted in: -pix_fmt rgb24 (High 4:4:4 Predictive), yuv444p(progressive) [02:49:02 CET] <ricemuffinball> it's still YUV but 4:4:4 [02:49:22 CET] <iive> so the Y channel is the luminosity (gray or b&w). and uv contain color information [02:50:04 CET] <iive> since the color is less important, yuv420 uses U and V channels with reduced resolution [02:50:06 CET] <pzy> you might have to process it as raw video ricemuffinball? not sure [02:50:11 CET] <pzy> see this load of technical stuff: https://forum.videohelp.com/threads/349890-YUV-4-2-0-to-RGB [02:50:29 CET] <ricemuffinball> i still yet to see a RGB video [02:50:56 CET] <iive> huffman should support it :) [02:53:33 CET] <ricemuffinball> since YUV is more popular, is it safe to say YUV is better than RGB ? [02:54:39 CET] <pzy> you'll never get anyone in a video engineering position to tell you something is better, unless they work for the company that sells it or spent way too much money implementing it :P [02:55:18 CET] <ricemuffinball> i still yet to see a RGB video [02:56:11 CET] <pzy> check archive.org [02:58:40 CET] <ricemuffinball> pzy i still cannot produce rgb video using ffmpeg [02:58:59 CET] <pzy> I really don't know enough about it [02:59:17 CET] <ricemuffinball> pzy but your command/option produced 4:4:4 video [14:54:17 CET] <sazawal> Hello. I want to convert a video clip into png images and get the associated timestamp. I tried this command, "ffmpeg -i input.mkv -vf "showinfo" -vsync 0 $framepath%04d.png -hide_banner >& output.txt". But sometimes the number of frames generated are more than the number of timestamps I get. How do I solve this? [14:57:39 CET] <durandal_1707> sazawal: put -vsync 0 before -i [15:01:03 CET] <sazawal> durandal_1707, Hi. It didn't solve the problem. Let me explain more, maybe I am doing some other mistake. [15:02:35 CET] <sazawal> I have split a video at every keyframe, and from this step I got many clips. When I use this command on the first clip, I get the same no. of frames and timestamps. But clip-1 and clip-2, I am getting one timestamp less than the number of frames. [17:44:43 CET] <famer> hi room [17:45:28 CET] <famer> I'm trying to continue interrupted encoding [17:45:53 CET] <famer> I'm using -ss to start from last seen timestamp in log [17:46:25 CET] <famer> do I have to skip header somehow, since I have it in first part [17:46:32 CET] <famer> I plan to join them later [17:53:40 CET] <AppAraat> hi, I'm trying to rotate a file (ffmpeg -i input.avi -c copy -metadata:s:v:0 rotate=180 output.avi) but it doesn't seem to apply that: https://bpaste.net/show/8dd5b4767556 [17:54:53 CET] <furq> i don't think avi supports rotate metadata [17:55:12 CET] <famer> AppAraat, it rotates only in a metadata(if command is correct) so your player have to support it, if I'm not wrong [17:56:40 CET] <AppAraat> yeah I'm aware that it only changes metadata (which is good since I don't want to re-encode) but mpv should be able to see the metadata and act accordingly. But yeah if avi doesn't support rotating metadata then my efforts are futile in terms of that ¯\_(Ä)_/¯ [17:57:04 CET] <furq> it's rawvideo so you might as well just use -vf rotate anyway [17:57:21 CET] <AppAraat> a more verbose output of me loading the rotating video for those interested: https://bpaste.net/show/7f6345613ae2 [17:57:28 CET] <AppAraat> oh hmm, yeah I might do that [17:57:55 CET] <furq> -c:v rawvideo -vf rotate=PI [17:59:01 CET] <AppAraat> is rotate=PI equivalent to rotate=180 ? [17:59:15 CET] <famer> so guys, anyway to skip header metadata in mp4? like ti does for junks in global_header? [17:59:22 CET] <furq> pi radians = 180 degrees [17:59:31 CET] <famer> AppAraat, you have to rotate in radians [17:59:53 CET] <AppAraat> oh I see, thanks. [18:00:09 CET] <furq> famer: you don't need to skip the header, the concat demuxer demuxes the streams before concatenating them [18:00:09 CET] <famer> clockwise_degreese*PI/180 [18:00:23 CET] <famer> furq [18:00:25 CET] <famer> thanks [18:01:37 CET] <AppAraat> [avi @ 0x559981399f00] yuv444p rawvideo cannot be written to avi, output file will be unreadable - oops :p [18:02:02 CET] <AppAraat> I'm just gonna see if mpv is going to be able to read it lol [18:04:25 CET] <durandal_1707> use NUT format [18:05:07 CET] <AppAraat> lol it somehow tripled he image [18:05:31 CET] <AppAraat> https://i.imgur.com/scrsL58.jpg [18:06:34 CET] <AppAraat> but it did flip it, this is the original: https://i.imgur.com/LTuPwwP.jpg [18:07:26 CET] <furq> i guess you need to convert it back to yuv422p [18:09:29 CET] <AppAraat> I'm reading about the NUT format but I have no clue how to convert it. I should specify using "-f fifo -fifo_format nut" ? [18:09:43 CET] <AppAraat> I'll take a look at flipping the image in Kdenlive if possible [18:09:51 CET] <AppAraat> (since I'm going to edit the video anyways) [18:12:08 CET] <durandal_1707> AppAraat: dont be clueless, just use .nut extension [18:12:44 CET] <AppAraat> oh it's an actualy extension. First time I'm hearing about it. [18:16:10 CET] <AppAraat> yeah that worked! yay :D [18:16:14 CET] <AppAraat> thanks :) [18:19:24 CET] <AppAraat> hmm, Kdenlive apparently can't import .nut files [18:22:21 CET] <durandal_1707> kdenlive is shit [18:23:25 CET] <AppAraat> they're supposedly refactoring entire codebase tho [18:23:35 CET] <AppAraat> but what video editor do you suggest otherwise? [18:27:34 CET] <furq> AppAraat: shotcut is apparently pretty good [18:29:19 CET] <AppAraat> heh, the same thing I've heard from durandal_1707 about kdenlive I heard about shotcut, but regardless I'll give it a try since I've never done so before. [18:29:44 CET] <furq> i've never tried either but shotcut should at least import nut since it uses libavformat [18:30:01 CET] <furq> you could also just try using mkv or converting the video back to yuv422p [19:36:28 CET] <AppAraat> furq: yeah I'll give shotcut a try because otherwise I'll have to convert first to .nut and then back again. Though the webcam recording I'll probably make in the future will be mjpeg anyway since I can get 30fps that way. [22:21:58 CET] <AlexP11223> I have mp4 with 2 audio tracks, how to replace them with different tracks from wav files (the same length)? [22:21:58 CET] <AlexP11223> I tried ffmpeg -i 1.mp4 -i a1.wav -i a2.wav -map 0:v:0 -map 0:a:1 -map 1:a:2 -c copy new.mp4 [22:21:58 CET] <AlexP11223> but got error Stream map '1:a:2' matches no streams. [22:21:58 CET] <AlexP11223> https://gist.github.com/AlexP11223/97215dd2331c0a0dc72c8093f7bae2ca [22:26:32 CET] <Ariyasu> isn't it 1:a:1 [22:29:14 CET] <relaxed> 1:a or 1:a:0 [22:29:30 CET] <relaxed> stream count starts at zero [22:31:21 CET] <AlexP11223> 2 is supposed to be input number [22:31:21 CET] <AlexP11223> before that I tried [22:31:21 CET] <AlexP11223> ffmpeg -i 1.mp4 -i a1.wav -i a2.wav -map 0:v:0 -map 1:a:0 -map 2:a:1 -c copy new.mp4 [22:31:40 CET] <relaxed> hmm, wait. ffmpeg -i 1.mp4 -i a1.wav -i a2.wav -map 0:v -map 1:a -map 2:a -c copy new.mp4 [22:33:01 CET] <AlexP11223> hm, got this now: [mp4 @ 000001f92d6d3540] Could not find tag for codec pcm_s16le in stream #1, codec not currently supported in container [22:34:21 CET] <relaxed> encode the audio to aac [22:35:07 CET] <relaxed> alac would be lossless, but it may not be supported on some playback devices [00:00:00 CET] --- Sat Mar 9 2019

1 0

ffmpeg-devel.log.20190307
by burek 08 Mar '19

08 Mar '19

[01:41:55 CET] <cone-813> ffmpeg 03Paul B Mahol 07master:7b966af930d4: avcodec/imm4: fix artifacts on some files with special coding mode [02:00:05 CET] <cone-813> ffmpeg 03Paul B Mahol 07master:0ce759defdab: avcodec/g723_1dec: actually decode second channel [08:11:45 CET] <pross> fate is a sea of yellow at the moment. who peed in the pool? [08:45:12 CET] <JEEB> pross: i think it shows which stuff is failing? [10:03:24 CET] <nevcairiel> new tests were added that seem to fail everywhere [10:52:47 CET] <pross> ok. the vsynth3 prores tests added in b38dd2d219c99996ca64259ce9d9deff00ad6afe are not deterministic [10:53:04 CET] <pross> they fail when '--enable-memory-poisoning' is used [11:05:35 CET] <nevcairiel> i let the author of those tests know, he is going to look into it [11:32:44 CET] <kurosu> exactly why I added those like 5 years ago, see RESIZE_OFF / INC_PAR_OFF if prores actually has format restrictions [11:44:38 CET] <durandal_1707> i like how ghidra deals with data references except it does not allow to jump to them from decompiler output [11:50:13 CET] <atomnuker> so you did try the spyware after all [12:05:56 CET] <kurosu> In soviet America, you spy with the spyware (sorry to Eastern Europeans) [12:09:00 CET] <atomnuker> I think the great chinese denuvo hackers have their own tools so they're safe [13:06:48 CET] <thardin> how decent is SCTP in ffmpeg? I see there's a protocol wrapper for it [13:39:34 CET] <thardin> ffplay sctp://radio.tranquillity.se:80 [13:40:27 CET] <thardin> only one listener at a time [00:00:00 CET] --- Fri Mar 8 2019

1 0

ffmpeg.log.20190307
by burek 08 Mar '19

08 Mar '19

[00:24:00 CET] <systemd0wn> Question: I'm having issues using the HLS muxer to take a mp4 as input, and output a single file. I've tried single TS and single fmp4 (wich outputs as m4s). Does anyone know if there are issues with using the -hls_flags "single_file" option in 4.1.1? (looking in bug tracker too) [00:29:01 CET] <systemd0wn> The issue being that it appears to work, I get my output files, and I can play them back. However, if I host those files on a web server and use that m3u8 as the input to convert it back to MP4 I see a lot of 'Non-monotonous DTS in output stream' messages and the output file is only ~2 of the expected 26 seconds. [00:30:18 CET] <systemd0wn> This is only ever an issue when I use the single_file flag. If I generate chunked TS files (remove the single_file flag), I don't see that issue when converting it back to mp4. [12:19:40 CET] <sazawal> Hello all. I want to change the brightness of a video in a specified time interval. I used mkvtoolnix to split the original file, and applied the brightness to the video segment. But now I cannot merge the segments back to one video using mkvtoolnix. Is there a way to change the of a video for a specified interval? [12:20:25 CET] <sazawal> Is there a way to change the brightness of a video for a specified interval? [12:21:04 CET] <BtbN> You have to 100% match the encoding parameters to be able to merge it back together. [12:21:14 CET] <BtbN> Otherwise you have to re-encode the whole thing. [12:22:14 CET] <sazawal> BtbN, When I used "-c:v copy" with the ffmpeg command it said, "Filtering and streamcopy cannot be used together." [12:23:10 CET] <BtbN> Well, it's right about that. [12:23:17 CET] <BtbN> Can't change the video without re-encoding [12:23:44 CET] <sazawal> BtbN, is there some way to do it? [12:24:13 CET] <BtbN> Just don't copy, but re-encode [12:24:32 CET] <BtbN> And make sure to match closely what the original video was parameter wise, then you can concat the 3 segments [12:25:10 CET] <sazawal> BtbN, Sorry, but how do I re-encode it? I guess I need to specify the codec which is the codec of the original file [12:25:16 CET] <BtbN> yes [12:26:02 CET] <sazawal> BtbN, When I checked the properties of the original video on nautilus, it says MPEG-4 Video (Advanced Simple Profile). How do I specify this codec in ffmpeg command? [12:26:31 CET] <BtbN> not sure actually, mpeg4 is a mess and it can be _a lot_ of different things, which might be outright impossible to reproduce [12:26:58 CET] <BtbN> It's also not exactly good. I'd say just re-encode the whole thing with x264 while you're at it. [12:28:27 CET] <sazawal> BtbN, Please correct me if I am wrong. First I will encode the whole thing with x264. Then split the file. Then apply the brightness to the video segment. Then merge it. [12:28:51 CET] <BtbN> no point in that extra encode step, pointless loss of quality. [12:29:22 CET] <BtbN> Just split it, re-encode all 3 segments, while filtering the middle one, and then concat them all together without re-encoding. [12:30:50 CET] <sazawal> I see. Yes, this should work. Could you please also give me a command for re-encoding with x264 with ffmpeg? Or I can use Handbrake, but there are so many parameters there that I may lose the quality. [12:31:23 CET] <BtbN> I'm at work, so can't. There's plenty of examples on the wiki though. [12:31:46 CET] <sazawal> BtbN, Let me check. But, thanks a lot. [16:52:23 CET] <ikonia> Hi guys, I'm trying to convert a flac audio file to an alac audio file, I'm using the command "ffmpeg -i file.flac -acodec alac file.m4a" [16:52:53 CET] <ikonia> I get the error "Could not find tag for codec h264 in stream #0, codec not currently supported in container" which from reading the docs suggests the code isn't supported in the m4a container [16:53:08 CET] <ikonia> (alac is fine in an m4a container) - what am I missing on this ? [16:59:49 CET] <pzy> same command works fine in my version of ffmpeg [17:00:39 CET] <ikonia> I'm on 4.0.3 from the fedora approved repos [17:00:41 CET] <ikonia> rpmfusion [17:01:25 CET] <pzy> you could try the -vn flag [17:01:32 CET] <pzy> since it seems to be some kind of weird video thing [17:01:39 CET] <ikonia> what does vn do [17:01:45 CET] <pzy> ignores any video in the file [17:01:46 CET] <pink_mist> I'd start with using ffprobe on the original file and checking if it doesn't have anything wonky inside [17:01:57 CET] <ikonia> interesitng that worked [17:02:14 CET] <pink_mist> right. you have a video in the flac file [17:02:16 CET] <pzy> sounds like your source flac has some video data in it [17:02:20 CET] <ikonia> I wonder if the flac files have the album art embedded [17:02:37 CET] <pink_mist> check with ffprobe [17:02:39 CET] <ikonia> that would explain it thinking it needed x264 and video [17:02:40 CET] <ikonia> yup [17:03:04 CET] <ikonia> Stream #0:1: Video: mjpeg, yuvj420p(pc, bt470bg/unknown/unknown), 360x374 [SAR 59:59 DAR 180:187], 90k tbr, 90k tbn, 90k tbc [17:03:07 CET] <ikonia> interesting [17:03:19 CET] <pzy> sheesh, metadata :P [17:03:19 CET] <ikonia> cover is listed as metadata [17:04:26 CET] <ikonia> thanks for the input, apprecaited [17:04:29 CET] <pzy> no problem [17:04:39 CET] <ikonia> hadn't considered that it may have seen the cover as video [17:18:09 CET] <kepstin> ikonia: alac isn't supported in app profiles of mp4/m4a container. It should work if you use "-f ipod", for example. [17:18:24 CET] <kepstin> in all profiles* [17:20:07 CET] <kepstin> oh, right, embedded cover art, nvm [17:20:36 CET] <kepstin> 'm4a' extension does map to a muxer that supports alac by default, yeah [17:34:47 CET] <brimestone> Good morning everyone.. [17:35:03 CET] <brimestone> Anyone know how to use VideoToolBox here? [17:56:27 CET] <brimestone> Hey guys, what does Direct Rendering Method 1 support means ? [18:00:47 CET] <^Neo> Hi, I'm trying to add support to alsa_dec.c to do spdif decoding and running into some problems. I'm including the spdif code from libavformat into libavdevice. My problem is that as I receive packets within the alsa_dec audio_read_packet and try to probe for the spdif start codes the temporary buffer that's created to do the temporary probing seems to become corrupted? a number of 0s get inserted in the [18:00:53 CET] <^Neo> middle of the temporary buffer between the start codes which mess up sync code calculations. [18:03:24 CET] <kepstin> brimestone: i'm not sure about any specifics regarding "method 1", but in ffmpeg in general, iirc direct rendering refers to codecs/renderers/devices that work directly on the image data in avframes without copying. [18:04:28 CET] <brimestone> Kepstin: ahhh this will eliminate the memcopy part which would save ram footprint and potentially time. Is it on by default? [18:04:46 CET] <^Neo> here's a pastebin with some snippets [18:04:48 CET] <^Neo> https://pastebin.com/F5nB1gNw [18:05:28 CET] <kepstin> brimestone: unless you're implementing an ffmpeg codec - or in some special cases a player - you should just ignore references to direct rendering. [18:06:30 CET] <^Neo> weird thing is that if I print the AVIO buffer contents then the code continues on until I hit a segfault when generating the spdif packet [18:06:32 CET] <brimestone> kepstin: how about for -vf lut3d or scaling? [18:08:20 CET] <kepstin> brimestone: very few filters implement dr, and scaling pretty much requires copying in many cases, especially when upscaling. [18:08:39 CET] <brimestone> And downscaling? [18:09:56 CET] <kepstin> i dunno. libswscale is complex and I haven't looked deeply into it [18:10:15 CET] <brimestone> Got it.. thanks. [18:10:17 CET] <kepstin> a multithreaded scaler could be nice for working with large images. [18:10:33 CET] <kepstin> but ffmpeg doesn't have that yet :) [18:10:39 CET] <brimestone> yes.. Im faced with this problem [18:11:17 CET] <brimestone> Is there a good book on how to use the library ? Say Swift or C? [18:23:59 CET] <deterenkelt> In the ffmpeg -version output, down below, where the library version are, what does the slash mean? [18:32:08 CET] <kepstin> deterenkelt: one of the numbers is the version ffmpeg cli tool was compiled against, the other is the version it loaded at runtime [18:32:19 CET] <kepstin> they should always match - if they don't, you have an installation problem [18:32:38 CET] <deterenkelt> kepstin oh, thank you. [21:57:24 CET] <harber> i'm on win10, doing something simple like => ffmpeg -hide_banner -f dshow -list_devices true -i null , and i get an exit code 1 when reading the response from golang, because i think the -i null or dummy creates an error code 1 [21:58:30 CET] <kepstin> harber: the "-list_devices" option causes the dshow input to error out, in order to stop ffmpeg from trying to read from the not-setup input [21:58:39 CET] <kepstin> harber: so that's working as expected. [21:58:44 CET] <harber> interesting [21:58:52 CET] <harber> so a perfectly working command errors, haha [21:59:10 CET] <kepstin> it's just because of where it's implemented in the layering [21:59:13 CET] <harber> i get it, it's just... interesting ;) [22:01:52 CET] <kepstin> if you use libavformat/libavdevice directly and pass the "list_devices" option when creating a dshow input, it'll do the exact same thing - log some output and fail to initialize. [22:02:32 CET] <kepstin> i don't actually know if there's a way to programmatically enumerate the input devices :) [22:03:07 CET] <harber> so i guess i need to let it error and read the stderr and if it looks like a result, regardless of error, that's what i need to parse [22:03:29 CET] <harber> more than anything, this points out that the previous languages i've been using didn't properly read that exit code, hahaha [22:05:12 CET] <harber> basically i wanted to make sure there wasn't an option like -ignore_input_error or something i could be flagging [00:00:00 CET] --- Fri Mar 8 2019

1 0

ffmpeg-devel.log.20190306
by burek 07 Mar '19

07 Mar '19

[06:35:37 CET] <cone-615> ffmpeg 03joepadmiraal 07master:056a2ac16813: avformat/dashenc: Added #EXT-X-PROGRAM-DATE-TIME to HLS playlists [09:50:56 CET] <JEEB> durandal_1707: ghidra seems really promising [09:51:04 CET] <JEEB> (NSA's open source reverse engineering tool) [09:57:45 CET] <durandal_1707> NSA? I'm feeling very secure right now. [11:09:27 CET] <thardin> cool, a whole bunch of those mxf hevc samples [11:09:47 CET] <JEEB> soon we should have some 22.2 samples [11:09:53 CET] <JEEB> (MMTP madness) [11:10:51 CET] <thardin> that starts to become somewhat significant bandwidthwise [11:12:32 CET] <JEEB> apparently some of the Japan 8K test airings [11:12:51 CET] <JEEB> we can play guesswork on which library we want to use for the IP packet parsing :P [11:13:02 CET] <JEEB> since MMTP recordings seem to be pure packet dumps [11:13:24 CET] <JEEB> and MMTP is madness of MPEG-TS-like variable length packet encapsulation -> IPv6|4 -> multicasts [11:13:35 CET] <JEEB> and those multicasts then finally contain MP4 fragments [11:21:18 CET] <nevcairiel> sounds similar to ATSC 3.0 where they married DASH and broadcast [11:31:43 CET] <JEEB> yea, I think both ARIB and ATSC spec'd both MPEG-TS and MMTP for next-gen broadcast :) [11:31:53 CET] <JEEB> MMTP being "perfect for hybrid" [11:32:04 CET] <JEEB> (in theory the streams can come either through the broadcast, or HTTP, or whatever) [11:32:49 CET] <kurosu> it's packet encapsulations all the way down [11:33:21 CET] <JEEB> yes [11:33:28 CET] <JEEB> all the layers of abstraction [11:40:08 CET] <atomnuker> "spec'd both MPEG-TS" <- that's a 30 year old standard with 188 byte packet sizes that was shit then and its shit now [11:40:18 CET] <JEEB> yes [11:40:27 CET] <JEEB> but it's not better than MMTP [11:40:30 CET] <JEEB> like, seriously [11:40:34 CET] <atomnuker> fits next gen broadcasting perfectly [11:41:08 CET] <JEEB> (Ž4@) [11:41:28 CET] <JEEB> they did variable length packets for MMTP's IP packetization [11:41:58 CET] <JEEB> too bad it was so many layers of stuff :P [11:43:05 CET] <JEEB> so it's no longer a media format, but rather the receiver will be a RX only network adapter [11:49:38 CET] <kierank> durandal_1707: JEEB: yes ghidra looks really interesting [11:49:46 CET] <kierank> ida without the piracy [11:54:37 CET] <atomnuker> "In the meantime, enjoy using Ghidra on your SRE efforts, developing your own scripts and plugins, and perusing the over a million lines of Java and Sleigh code" [11:55:17 CET] <atomnuker> is c++ not corporate enough anymore for a huge gov't agency? [12:03:03 CET] <nevcairiel> i never even heard of sleigh [12:04:14 CET] <kierank> atomnuker: probably they wanted multiplatform ui and started before qt [12:22:32 CET] <thardin> hum hum.. how do I add a simple FATE decode test again? [12:23:18 CET] <thardin> looks like h264-conformance-* are good cribs [12:23:56 CET] <thardin> ah but yes, since this is hevc in mxf perhaps I should only test demux [12:25:19 CET] <nevcairiel> you can test both, but of course the focus should be on what you really want to test, the mxf demuxer or the hvec decoder [12:25:32 CET] <thardin> indeed [12:26:31 CET] <thardin> why is there a demux.mak with fate-mxf-demux when there is also mxf.mak with a bunch of demux tests? [12:27:55 CET] <nevcairiel> demux.mak used to collect single demuxing tests of various formats, and when a format got more complex tests they end up in their own file. Sometimes, the former is not removed when the latter happens [12:29:38 CET] <thardin> right. and diego split off that file in 2011 even [12:30:04 CET] <thardin> and then mxf.mak came along in 2015 [12:31:33 CET] <thardin> let's see if it isn't possible to use a big 'ol list in this thing since there's 25 samples [12:34:49 CET] <thardin> something like fate-mxf-xf-hevc-%: CMD CMD = framecrc -i $(TARGET_SAMPLES)/mxf/xf-hevc/%.mxf -c:v copy [12:34:59 CET] <thardin> err minus on CMD [12:36:02 CET] <nevcairiel> we use something like that for the h264 ref samples you already found, so that should definitely cut down the number of lines [12:36:39 CET] <nevcairiel> actually h264 only does it half [12:36:47 CET] <nevcairiel> hevc ref samples does it properly [12:37:03 CET] <nevcairiel> with a loop and everything [12:38:07 CET] <thardin> I'm thinking I can just add a bunch of FATE_MXF += fate-mxf-xf-hevc-2500p-1080-45M [12:38:18 CET] <thardin> where 2500p-1080-45M is the name of the sampel [12:40:35 CET] <thardin> didn't know make had $(foreach) [12:40:58 CET] <thardin> then I only need to figure out how to have it spit out refs the first time around [12:41:27 CET] <nevcairiel> run make with GEN=1, that'll generate files instead of trying to compare to them [12:42:33 CET] <thardin> cool [12:42:46 CET] <thardin> hm no, it's empty [12:44:31 CET] <thardin> ./ffprobe -show_packets shows it demuxes ok, and I can transcode it [12:47:13 CET] <thardin> ah it's the % replacement that's not working [12:47:36 CET] <thardin> I'll just do what the HEVC test does then [12:51:43 CET] <thardin> success! [12:56:49 CET] <durandal_1707> this codec is ugly and uses floats a lot [13:02:14 CET] <thardin> and also it fails as expected when the patch isn't applied [13:14:42 CET] <thardin> this matthew fellow went off-list for some reason, so I'll wait for him to ACK it. but I suspect that was just by mistake [13:15:38 CET] <durandal_1707> what? [13:15:51 CET] <nevcairiel> some mail clients fail at mailing list responses [13:16:02 CET] <thardin> indeed [13:16:23 CET] <nevcairiel> especially if you CC the people in that thread, which is really annoying [13:16:40 CET] <nevcairiel> not sure why people do that, isnt everyone subscribed anyway :) [13:17:11 CET] <thardin> I think they just hit reply all and it gets to From: as well [14:43:45 CET] <thardin> did my mxf-hevc mail make it properly to the list? I had some e-mail client issues [20:32:37 CET] <cone-813> ffmpeg 03Paul B Mahol 07master:93402561fda4: avcodec/imm4: add support for mid-stream size changes [20:34:11 CET] <durandal_1707> why GPL2 for checkasm license of v210? [20:36:16 CET] <kierank> Came from x264 I guess [20:37:03 CET] <durandal_1707> GPL is cancer [20:40:09 CET] <J_Darnley> Yes, it is. It does ensure you get source code for things used over a network. [20:40:14 CET] <J_Darnley> *doesnt [20:41:01 CET] <J_Darnley> Also I just submitted a very dumb patch [20:41:18 CET] <durandal_1707> AGPL is murder [20:42:54 CET] <J_Darnley> Honestly it is gpl because I just started it with the v210enc checkasm file which is also gpl [20:43:58 CET] <durandal_1707> ok [20:44:33 CET] <JEEB> durandal_1707: https://www.nsa.gov/resources/everyone/ghidra/ [20:44:38 CET] <JEEB> this is the thing that NSA released [20:44:44 CET] <JEEB> seems surprisingly good [20:46:15 CET] <durandal_1707> JEEB: please stop sending me good linux rootkits, my system already belongs to Carl [20:47:52 CET] <durandal_1707> i will use it once full source code (including for decompiler) is put somewhere (github) [20:48:08 CET] <JEEB> yup [20:50:40 CET] <j-b> tsup [20:52:51 CET] <j-b> durandal_1707: IMM5? :D [20:52:55 CET] <atomnuker> durandal_1707: there is a repo and they're working on actually uploading it there [20:53:10 CET] <atomnuker> but I still would be somewhat skeptical about its usability as its java [20:53:21 CET] <atomnuker> and some other lang without a wiki page [20:53:30 CET] <JEEB> marcan tried it and it seemed really nice [20:53:38 CET] <JEEB> https://twitter.com/marcan42/status/1103186324394205184 [20:54:43 CET] <j-b> marcan is not a name I like [20:55:08 CET] <JEEB> don't like console hacking? [20:55:20 CET] <JEEB> although I don't think he's done much after PS4 [20:57:33 CET] <durandal_1707> j-b: i'm busy with AC-4, IMM5/CFHD?!? will happen latter [20:58:18 CET] <j-b> JEEB: he's a twitter bully. Really not my type [20:58:32 CET] <JEEB> interesting [21:00:53 CET] <j-b> JEEB: but I love console hacking. It is sooo fun [23:46:53 CET] <cone-813> ffmpeg 03Michael Niedermayer 07master:53248acfb3b2: avcodec/scpr: Fix use of uninitialized variable [00:00:00 CET] --- Thu Mar 7 2019

1 0

ffmpeg.log.20190306
by burek 07 Mar '19

07 Mar '19

[00:01:40 CET] <omani> hi guys. I have a really hard time to figure out how to merge two videos as such that the second video starts 5 seconds before the first video ends. (trying to append an outro video) [00:02:21 CET] <omani> the second video has music in it. so right before the first one ends (someone is speaking until the end) the second video's music should start. [00:02:26 CET] <omani> is this even possible with ffmpeg? [00:03:20 CET] <omani> I guess anything is possible with ffmpeg. [00:03:31 CET] <c_14> use the trim filter to split the first and second video/audio tracks into 2 parts each, the part where only they play and the 5 second part where they overlap [00:03:52 CET] <c_14> blend the 5second video tracks, amix the 5second audio tracks, use the concat filter to put the parts into the right order [00:12:42 CET] <omani> c_14: ok thanks [01:18:35 CET] <jennx> heya [01:18:52 CET] <systemd0wn> Question: I have a m3u8 (~26 seconds) that I've generated with ffmpeg (single TS output) and would like to use that as an input and mp4 as an output. However, when I do so I end up with ~ 2 second file and logs show "root atom offset 0x1c0278: partial file" and "Non-monotonous DTS in output stream 0:1; previous: 95782, current: 45565; changing to 95783. This may result in incorrect timestamps in the [01:18:58 CET] <systemd0wn> output file." I'm happy to share more information like commands used, sample files, etc. I'm curious why ffmpeg exits 0 after turning a 26 second file into a 2 second file. I'm curious what I did the the original file or playlist to cause these time related log entries. [01:19:10 CET] <jennx> are CPU x264 hardware encoders used automatically with ffmpeg or do i have to supply a switch? [01:19:53 CET] <brimestone> JEEB - I've had it.. Im setting up a Z840 with 2 nVidia Tesla cards :) running ubuntu.. lets see what kind of speed ill get with these. [01:21:06 CET] <kepstin> jennx: if you want a specific encoder, you have to manually specify it. [01:21:33 CET] <kepstin> jennx: note that libx264 is a specific software encoder [01:22:51 CET] <systemd0wn> jennx: https://trac.ffmpeg.org/wiki/HWAccelIntro may also be helpful [01:25:07 CET] <jennx> ta [01:36:57 CET] <kepstin> huh, fun, the hevc_vaapi encoder on my RX 560 only works in constant-qp mode. If i try setting a bitrate instead, I get garbage. [01:37:13 CET] <kepstin> (it's garbage at the requested bitrate, so that's something at least) [01:37:32 CET] <kepstin> tbh, I'm kinda surprised it works at all, the h264 encoder doesn't work :) [02:42:05 CET] <Sauraus> Hi there [02:42:59 CET] <Sauraus> I was wondering if anyone has tried capturing Twitch life streams on a EC2 instance in AWS and if they ran into any weird connectivity issues. [02:43:50 CET] <Sauraus> My command line and subsequent errors can be found in this gist https://gist.github.com/Sauraus/1848aefefa5c27c134d6d3ad22e534c6 [02:45:03 CET] <Sauraus> When I run that command on my local workstation it runs flawlessly for hours on end, but on an c5m.xlarge EC2 instance on AWS the life video feed capture is very jerky and unreliable [10:41:07 CET] <th3_v0ice> Am I understanding the code correctly that if I set AVFMT_TS_NONSTRICT, this will omit the check(cur_dts < prev_dts) and will send a packet to the output? [11:21:55 CET] <slingamn> i'm having trouble finding a guide on extracting subtitles from a DVD's .vob files [11:22:15 CET] <slingamn> https://stackoverflow.com/questions/19200790/converting-dvd-image-with-subt… this is the closest thing i've seen [11:25:44 CET] <slingamn> this is the closest i've gotten: [11:25:49 CET] <slingamn> ffmpeg -fflags +genpts -analyzeduration 1000000k -probesize 1000000k -i /mnt/usbstick/VIDEO_TS/VTS_01_1.VOB -c:s copy -map 0:3 /home/shivaram/holding/holding/mymovie.sub [11:26:07 CET] <slingamn> which produces: [11:26:08 CET] <slingamn> [microdvd @ 0x560a19b18ec0] Exactly one MicroDVD stream is needed. [11:26:52 CET] <furq> there's no vobsub muxer [11:27:09 CET] <furq> you can extract the subtitles into mkv or something [11:27:29 CET] <slingamn> that would work [11:27:56 CET] <furq> bear in mind the palette will probably be broken because that's stored in the corresponding ifo [11:28:51 CET] <slingamn> i get "[matroska @ 0x55f527354f60] Only audio, video, and subtitles are supported for Matroska.5.64x" [11:29:11 CET] <furq> what ffmpeg version [11:29:16 CET] <slingamn> hmm, it might be mad about this: "Stream #0:2: Data: dvd_nav_packet" [11:29:26 CET] <slingamn> 3.4.4-0ubuntu0.18.04.1 [11:30:04 CET] <furq> weird [11:30:08 CET] <furq> that works here on 3.4.2 and 4.1 [11:30:17 CET] <slingamn> ah so this worked: [11:30:18 CET] <slingamn> ffmpeg -fflags +genpts -analyzeduration 1000000k -probesize 1000000k -i /mnt/usbstick/VIDEO_TS/VTS_01_2.VOB -c:s copy -map 0:3 ./out.mkv [11:31:02 CET] <slingamn> mkvinfo shows S_VOBSUB data successfully extracted in the outfile [11:31:15 CET] <furq> anyway if the palette is broken then try -ifo_palette VTS_01_0.IFO and remove -c:s copy [11:31:40 CET] <furq> or rather change it to -c:s dvdsub [11:32:33 CET] <slingamn> what file extension should i use with -c:s dvdsub? [11:32:49 CET] <furq> still mkv [11:33:42 CET] <furq> it's just decoding and reencoding to the same format [11:33:48 CET] <slingamn> ah [11:33:57 CET] <furq> ifo_palette is a dvdsub decoder option for boring technical reasons, so it doesn't work with stream copy [11:34:05 CET] <furq> but it should be lossless anyway [11:34:27 CET] <slingamn> so the dvd is split into 3 vob files, and my ultimate goal is to create a single detached subfile [11:35:43 CET] <furq> you probably want to use an actual tool that will spit out a contiguous dvd title then [11:36:00 CET] <furq> sometimes you'll get lucky and the split vob set is exactly one title, but usually there's some other stuff on there [11:36:15 CET] <furq> normally on *nix i use tccat (part of transcode) and pipe it to ffmpeg [11:36:36 CET] <furq> if you're sure it's exactly one title then you can literally just cat the vobs together [11:36:59 CET] <slingamn> interesting [11:37:19 CET] <slingamn> `-i -` is stdin? [11:39:11 CET] <JEEB> yes [11:39:29 CET] <JEEB> "-" is stdin in many media apps [11:54:07 CET] <slingamn> oh this is neat [11:54:12 CET] <slingamn> i was able to do it with subtitleripper [11:54:29 CET] <slingamn> cat /mnt/usbstick/VIDEO_TS/VTS_01_*.VOB | tcextract -x ps1 -t vob -a 0x20 > mysub.ps1 [11:54:40 CET] <slingamn> subtitle2vobsub -i /mnt/usbstick/VIDEO_TS/VTS_01_0.IFO -p ./mysub.ps1 -o mymovie [16:11:33 CET] <pax_rhos> hello, how to record audio not from mic, but from output using ffmpeg? [16:16:39 CET] <pax_rhos> I use pulseaudio [16:30:42 CET] <relaxed> pax_rhos: https://ffmpeg.org/ffmpeg-devices.html#pulse [16:52:30 CET] <pax_rhos> I've read that [16:53:59 CET] <relaxed> you're trying to capture something playing through pulseaudio? [16:54:10 CET] <pax_rhos> yes [16:54:14 CET] <pax_rhos> skype video chat [16:55:16 CET] <relaxed> while using skype, run "pactl list sources" and maybe it will list its name or something obvious [16:56:33 CET] <relaxed> then use that name instead of "default" [16:56:42 CET] <pax_rhos> oh, I thought I could address streams by their number [16:56:49 CET] <pax_rhos> turns out I should in fact use name [16:56:54 CET] <pax_rhos> even though it's damn long [16:58:47 CET] <pink_mist> copy+paste? [17:37:11 CET] <brimestone> Hey guys, help me understand this.. Im doing this. "ffmpeg -i <ProRes444 4k>.mov -f null -" and all I get is "speed=0.337x" - which means if I add -vf to it - its just going to make it slower.. how can I make the decoding faster? [17:38:07 CET] <furq> the prores decoder apparently supports threading [17:38:16 CET] <furq> so try adding -threads 4 before -i [17:38:22 CET] <furq> (or whatever number you want) [17:38:24 CET] <brimestone> Testing now.. [17:40:29 CET] <brimestone> oh wow, it works.. [17:40:42 CET] <brimestone> Im getting 1.4x now [17:43:13 CET] <brimestone> Awesome.. thanks.. [17:43:44 CET] <brimestone> But then if I add this "-vf scale=-1:720" it shoots it down back to 0.6x [17:45:06 CET] <Mavrik> Are you sure there's no encoding going on? [17:45:13 CET] <Mavrik> Also how slow is the machine that it gets killed by scaling? O.o [17:47:29 CET] <DHE> you should see a line like: "Stream #0:0 -> #0:0 (prores (native) -> wrapped_avframe (native))" which indicates it's outputting to wrapped_avframe (which will be effectively not reencoding). an uncompressed format would also be fine. [17:47:51 CET] <brimestone> Its this https://www8.hp.com/us/en/workstations/z840.html [17:48:13 CET] <DHE> there's also the more detailed output description section but it's not so copy/paste friendly in IRC [17:48:23 CET] <brimestone> With nvidia Quadro K4200 [17:48:46 CET] <DHE> GPU means nothing in this config [17:49:19 CET] <brimestone> DHE checking the avframes now [17:49:51 CET] <brimestone> Stream #0:0 -> #0:0 (prores (native) -> wrapped_avframe (native)) [17:50:24 CET] <brimestone> and this is 0:0 - Video: prores (ap4h / 0x68347061), yuv444p10le(bt709, progressive), 4480x3096, 1815020 kb/s, SAR 1:1 DAR 560:387, 24 fps, 24 tbr, 24 tbn, 24 tbc (default) [17:50:40 CET] <DHE> that's the input... that's higher than 4k [17:50:50 CET] <brimestone> :) [17:50:58 CET] <DHE> and yuv444... [17:51:03 CET] Action: DHE wipes the drool [17:51:30 CET] <Mavrik> Yeah, you might be having unrealistic expectations about performance then :P [17:51:58 CET] <Mavrik> Isn't there a nvidia scaling filter somewhere? [17:52:41 CET] <brimestone> I ran the same task - which is -vf scale=-1:720:lut3d="ARRI_EE_LogC_R709.cube" on DaVinciResolve and man! it was doing It around 2.4x [17:52:42 CET] <furq> does nvdec support prores at all [17:52:49 CET] <furq> much less 4:4:4 at >4k [17:53:14 CET] <DHE> no, which means you'll have to move the frames in/out of the GPU which might be another possible slowdown point [17:53:21 CET] <DHE> (not that I know what it's capable of) [17:53:36 CET] <furq> the support matrix on nvidia.com doesn't mention it [17:53:41 CET] <Mavrik> the idea was more like if you could do hwupload,scale,hwdownload [17:53:46 CET] <furq> but also it's on nvidia.com so i don't believe what it has to say [17:53:49 CET] <Mavrik> But yeah, resolution support is questionable [17:55:08 CET] <brimestone> When Resolves does its it uses all the cores on the CPU and all the cores on the GPU.. which got it to do ~2.4x [17:57:34 CET] <DHE> they may be running a custom application which does even more multi-threading. I don't think the scale filter is multi-threaded [17:57:49 CET] <brimestone> Got it.. [17:57:58 CET] <DHE> (that's what I'm doing) [17:58:10 CET] <furq> maybe try zscale if your build has it [17:58:23 CET] <brimestone> zscale? [17:58:32 CET] <furq> it's a different scaling filter [17:58:40 CET] <furq> it might have a faster path for this, idk [17:59:21 CET] <brimestone> testing.. [18:01:13 CET] <brimestone> Both my Linux and macOS doesn't have zscale. Is it suppose to be faster? [18:01:40 CET] <furq> like i said, idk [18:01:45 CET] <furq> in my experience it's sometimes faster [18:02:03 CET] <brimestone> thanks.. this has got me further than before.. [18:02:03 CET] <furq> apparently there is some private apple api for prores hwdec [18:02:08 CET] <furq> so maybe resolve is using that [18:02:27 CET] <brimestone> I'm also investigating that now.. AVFoundation + VideoToolBox [18:03:04 CET] <furq> no idea if ffmpeg can use that avi [18:03:05 CET] <furq> api [18:03:12 CET] <furq> i would assume not but i have no idea how avfoundation works [18:32:33 CET] <angular_mike_> Is it possible with ffmeg to pack individual opus framed on input into an ogg container file on output without decoding to pcm? [18:34:53 CET] <DHE> yeah, just set the codec to "copy" [18:53:15 CET] <angular_mike_> DHE: how do I input them tho? [19:39:03 CET] <kepstin> angular_mike_: how are they framed? ffmpeg has to know how to read that framing mechanism [19:39:25 CET] <kepstin> opus itself doesn't have a raw format, since the packets rely on having length signalled through the container/framing [19:44:05 CET] <angular_mike_> kepstin: raw frames interecepted from discord API [19:44:14 CET] <angular_mike_> bytes [19:45:13 CET] <kepstin> angular_mike_: to feed them to the ffmpeg cli tool, you have to put the opus packets into a bytestream with framing that indicates their length. in other words, you're gonna have to mux them into a container in order to input them to the ffmpeg cli. [19:45:24 CET] <JEEB> sounds like you might as well use the lavf API :P [19:45:31 CET] <JEEB> if you are already intercepting packets [19:45:36 CET] <kepstin> if you're using ffmpeg libraries, you could just put the opus data int AVPacket structures, yeah [19:45:46 CET] <angular_mike_> kepstin: here is how are they received https://github.com/b1naryth1ef/disco/blob/master/disco/voice/opus.py [19:48:46 CET] <angular_mike_> kepstin: my bad, i think it's actually this: https://github.com/b1naryth1ef/disco/blob/305f1800c17062f962674ba1cfae69517… [19:49:16 CET] <angular_mike_> kepstin: I'm trying to minimize unecessary transcoding [20:55:00 CET] <GuiToris> hello, ffmpeg values can't be animated, can they? [20:56:08 CET] <kepstin> GuiToris: some filters support evaluating expressions in their parameters every frame, effectively allowing you to animate them [20:56:32 CET] <kepstin> this is typically mentioned in the filter docs. [20:58:01 CET] <GuiToris> kepstin, it seems perspective filter has such option [20:58:06 CET] <GuiToris> how does it work? [20:58:31 CET] <GuiToris> I see two options eval init or eval frame [20:59:37 CET] <GuiToris> https://ffmpeg.org/ffmpeg-filters.html#perspective [20:59:43 CET] <GuiToris> I don't see anything like that [21:00:10 CET] <kepstin> the rotate filter has some good examples: https://www.ffmpeg.org/ffmpeg-filters.html#Examples-92 that make your video spin or oscillate. [21:00:33 CET] <kepstin> other filter usually work similarly, but you have to check the docs *on each filter* to find out what variable names are available [21:01:34 CET] <kepstin> (note that in the rotate filter examples, you have to replace `T` and `A` with numbers to run them) [21:01:34 CET] <GuiToris> wow, it doesn't look easy, but I'll give it a shot [21:02:04 CET] <kepstin> yeah, any animation you do have to be expressed in terms of time [21:02:37 CET] <kepstin> it's not "animate from here to there", it's "calculate how far between here and there it is at time t" [21:03:07 CET] <GuiToris> I have the right values and I tried them with ffmpeg it looked okay, I wanted to try it with after effects and I used the very same numbers but the output was way different [21:03:13 CET] <GuiToris> do you happen to know the reason? [21:03:33 CET] <kepstin> GuiToris: i have no idea what numbers or effect you're talking about, so that question is meaningless [21:03:59 CET] <GuiToris> I'll show you and it will make much more sense [21:04:56 CET] <kepstin> as far as it goes in general, you should read the ffmpeg docs, read the after effects docs, find out what the meaning of the parameters are, and translate them if it makes sense to do so. [21:06:53 CET] <kepstin> if this is about the perspective filter in particular, note that ffmpeg uses sense=source by default, which is basically an inverse transform - you specify the locations of the corners in the source video, and it pulls those out to the corners of the destination video [21:07:09 CET] <kepstin> it's possible that AE goes in the other direction. [21:08:06 CET] <GuiToris> wait, what? inverse transform? [21:08:30 CET] <GuiToris> how can I calculate the other values? [21:08:35 CET] <GuiToris> this must be the problem [21:08:54 CET] <GuiToris> with aftereffects I have no other options but the basic xy coordinates [21:09:39 CET] <GuiToris> I saw this source and destination options but I don't understand them [21:10:23 CET] <kepstin> i have no idea how to convert the values. I know they can be converted, but I don't know the formulas. If you know some linear algebra it shouldn't be hard to work out. [21:10:48 CET] <GuiToris> oh yeah, changing it to destination I get the very same output which is not what I want [21:29:25 CET] <GuiToris> I can't figure it out, if anyone know how to convert values between 'source' and 'destination' please let me know [21:35:31 CET] <GuiToris> kepstin, I assume you don't know but I have found another tool inside aeffects which has an 'unstretch' option, and I'm not 100% sure but it looks okay, do you think this is the source/destination switch? [21:36:06 CET] <kepstin> no idea, i've never used AR [21:36:08 CET] <kepstin> AE* [21:37:18 CET] <GuiToris> I'll compare them but I think that's what I wanted, thank you for your time and help kepstin [21:37:52 CET] <durandal_1707> options are just x/y coordinates [21:39:41 CET] <GuiToris> that's what I also thought [21:40:36 CET] <kepstin> yeah, but the x/y coordinates have to be different to get the same result depending on whether the forwards or reverse transform (sense=source, sense=destination) is selected [21:41:32 CET] <kepstin> the "forwards" perspective transform is normally you take the existing corners of the image and then pull them to the specified coordinates (sense=destination) [21:41:58 CET] <kepstin> ffmpeg defaults to a reverse transform, where you specify x/y coordinates of spots within the image frame, and then they get pulled to the corners of the image. [21:52:40 CET] <GuiToris> the original image: https://ptpb.pw/nhz9 , code: ffmpeg -i original.jpg -vf perspective=-32:73:1895:28:5:1125:1927:1060 ffmpeg.jpg output: https://ptpb.pw/kOxZ after effects: https://ptpb.pw/YuBl then I found this: https://ptpb.pw/W5D9 [21:52:49 CET] <GuiToris> this looks really similar [21:53:20 CET] <GuiToris> I think that button is the sourse/destination switch in aftereffects [21:53:47 CET] <GuiToris> I haven't rendered the image so I could compare them but it's much better than before [21:54:04 CET] <GuiToris> I don't know why I needed a separate effect for this [23:07:14 CET] <angular_mike_> `fmpeg -i in.pcm -f s16le -ar 48k -ac 2 out.ogg` gives me `in.pcm: Invalid data found when processing input` while `play -t raw -r 48k -e signed -b 16 -c 2 in.pcm` plays audio [23:07:18 CET] <angular_mike_> what's wrong? [23:08:56 CET] <durandal_1707> angular_mike_: wrong order of options [23:09:08 CET] <angular_mike_> wdym? [23:09:31 CET] <kepstin> angular_mike_: your options are in the wrong order [23:09:38 CET] <angular_mike_> what's the right order? [23:09:39 CET] <durandal_1707> angular_mike_: move -i in.pcm after -ac 2 [23:09:44 CET] <JEEB> input options before input [23:09:47 CET] <angular_mike_> huh [23:09:49 CET] <angular_mike_> weird [23:09:50 CET] <JEEB> output options after input and before output [23:10:25 CET] <angular_mike_> what goes after output then? [23:10:34 CET] <kepstin> `ffmpeg -f s16le -sample_rate 48000 -channels 2 -i in.pcm out.ogg` [23:10:47 CET] <JEEB> angular_mike_: you can put another output after the first etc [23:10:50 CET] <kepstin> anything after the output filename will be applied to the next output filename [00:00:00 CET] --- Thu Mar 7 2019

1 0