[Ffmpeg-devel-irc] ffmpeg.log.20190310
burek
burek021 at gmail.com
Mon Mar 11 03:05:23 EET 2019
[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/0567db70d474193e45dc0921b90b0619acfb03cb
[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-0x8bd7fe90-in-parent-when-trying-to-do-anything 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‡ íü¨ó°êó ïü°Êü\òSnB“o+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/a0ac49e38ee1d1011c394d7be67d0f08b2281526/libswscale/swscale.h#L176
[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
More information about the Ffmpeg-devel-irc
mailing list