August 2018 - Ffmpeg-devel-irc

ffmpeg-devel.log.20180820
by burek 21 Aug '18

21 Aug '18

[02:33:45 CEST] <cone-494> ffmpeg 03Michael Niedermayer 07master:dbac849c4db9: avcodec/lagarith: Optimize FRAME_SOLID_RGBA [02:33:45 CEST] <cone-494> ffmpeg 03Michael Niedermayer 07master:2c1613ac94d0: avcodec/cfhd: Move peak_table() and difference_coding() calls after the existing coefficient count check [02:33:45 CEST] <cone-494> ffmpeg 03Michael Niedermayer 07master:77429b4217bd: avcodec/cfhd: Use the actual count instead of the expected in peak_table() [02:33:45 CEST] <cone-494> ffmpeg 03Michael Niedermayer 07master:78d4b6bd43fc: avformat/nsvdec: Do not parse multiple NSVf [03:39:12 CEST] <BBB> jamrial: have you changed your mind about VDD? I dont know how to beg you, please consider coming [03:39:23 CEST] <BBB> I fly from far also, its not great but its not that bad [03:39:37 CEST] <BBB> so do several others [03:40:23 CEST] <jamrial> BBB: it's not the distance, it's just something too overwhelming for me [03:40:52 CEST] <BBB> youthink well swarm you like flies and eat you? [03:41:41 CEST] <jamrial> no, my insecurities will :p [03:41:53 CEST] <BBB> youre not the only geek there, everyone is [03:42:10 CEST] <BBB> geek isnt even forbidden by the CoC, because its a fact [03:42:48 CEST] <BBB> this is probably hard to imagine if youdont attend more often, but its really quite fun, even if you dontknow anyone or dont quite know what to expect [03:43:23 CEST] <BBB> most of us are not there to troll, just to meet face-to-face and be able to discuss some items with everyone in the same timezone and nobody being able to randomly afk for whatever reason [03:43:34 CEST] <BBB> it really does help to have everyoe present and read facial expressions [03:43:56 CEST] <BBB> jb pays for everything, and its fun, please consider it [03:43:58 CEST] <BBB> were not terrible [03:44:09 CEST] <BBB> we need more not-terrible, even pleasant, people [03:45:28 CEST] <jamrial> i know [03:48:26 CEST] <atomnuker> overwhelming? I too used to feel like that just thinking of travelling to an unknown big city [03:48:31 CEST] <BBB> and if you need some time alone, dont forget that paris is one of the most beautiful cities in europe [03:48:39 CEST] <BBB> you can always sneak out for a bit and enjoy the city [03:48:56 CEST] <BBB> (<secret> FREE PARIS TRIP !!! </secret>) [05:26:59 CEST] <rcombs> should I go to that [06:16:19 CEST] <Compn> rcombs : its interesting [06:16:51 CEST] <Compn> i'd guess a few of us have crippling anxiety [06:18:16 CEST] <atomnuker> yeah, getting on a single bad flight surrounded by kids is enough to make anyone have axiety issues before flying [06:19:18 CEST] <Compn> i was on a 9 hour flight sitting beside a nanny and 4 kids who were told to scowl at me until they fell asleep, at which point the nanny spent the remainder of the flight talking loudly on the phone [06:19:29 CEST] <Compn> so yeah that was a lot of fun [06:22:32 CEST] <rcombs> I don't really have problems with travel; I do it often enough [06:24:19 CEST] <Compn> paris is fun though [06:34:01 CEST] <atomnuker> if you go north of Gare du Nord (which you have to to get a useful metro line) you'll almost believe you're in Brick Lane or New Cross [08:52:43 CEST] <JEEB> heh, low bit rate data streams are "fun" in MPEG-TS with FFmpeg since they can cause the probing just go on and on if you happen to press that "probe stream" API :) [08:53:41 CEST] <JEEB> with a file it's a no brainer since you get to the EOF rather quickly [11:16:25 CEST] <JEEB> alright, limited the H.264 breakage sample to 10MiB [11:16:59 CEST] <JEEB> (some GOPs decode'able, and then the issue hits, which continues to the following GOPs) [11:17:23 CEST] <JEEB> (although looking at the header tracing it should only be 12 packets that are borked) [11:23:11 CEST] <JEEB> https://kuroko.fushizen.eu/samples/2018-08-17-h264_decoder_borks.cut.ts [12:25:34 CEST] Action: JEEB wonders where to start with the H.264 decoder [12:27:20 CEST] <JEEB> it should be getting new PPS/SPS and whatever reference count containing stuff, but it seems to always be lacking some refs [12:28:43 CEST] <JEEB> http://up-cat.net/p/071386c4 [12:28:52 CEST] <JEEB> the "default" it outputs seems to be somewhat high int-wise, too :D [12:56:07 CEST] <JEEB> hmm [12:56:14 CEST] <JEEB> h264_fill_mbaff_ref_list stops getting called [12:58:19 CEST] <JEEB> http://up-cat.net/p/b1472463 and those Perkele1/2 logs stop showing up [12:58:29 CEST] <JEEB> while before that they were getting called [13:12:16 CEST] <JEEB> wait, did the stream just randomly switch from MBAFF to PAFF... [13:25:42 CEST] <kierank> JEEB: that's allowed [13:31:31 CEST] <JEEB> yea [13:31:43 CEST] <JEEB> it's just that something's going awry regarding refs [13:31:47 CEST] <JEEB> in the decoder [13:34:36 CEST] <kierank> doesn't suprise me [13:34:51 CEST] <kierank> I'd like to build a "super-fate" at work around this kind of thing [14:00:08 CEST] <gh0st__> I have tested SIMD optimizations on a Ryzen 5 cpu with checkasm --bench and it seems that in most cases there are no speed benefits for avx2 instruction set or worse it is even slower than:ssse3, avx... Is this because of the half throughput that Ryzen 5's avx2 has compared to intel cpus? [14:00:49 CEST] <Gramner> gh0st__: ryzen only have 128-bit SIMD, so avx2 generally doesn't make things faster [14:03:07 CEST] <gh0st__> Well, that's unfortunate. [14:05:13 CEST] <gh0st__> Then the question is: if it doesn't speed things, then why did they introduced avx2 in their chips? [14:05:23 CEST] <nevcairiel> tick in the feature list [14:05:58 CEST] <Gramner> it's useful if you only want to write avx2 and not bother with older code, that's about it [14:06:33 CEST] <gh0st__> Alright, then I hope we will see 256-bit SIMD on zen2 I guess. [14:06:50 CEST] <Gramner> possibly [14:06:57 CEST] <Gramner> or zen3. or 4. or 5. [14:07:06 CEST] <Gramner> it'll get implemented eventually [14:16:02 CEST] <January> jkqxz: jamrial said you had a patch for h264_metadata_bsf which allowed adding multi-field data in sei? [14:24:13 CEST] <jkqxz> January: For captions? I have <https://github.com/fhvwy/FFmpeg/commits/cbs>, but it doesn't have any special handling for fields. [18:11:15 CEST] <kierank> durandal_1707: bug last night was -1 * (x >> n) != ((-x) >> n) [18:11:19 CEST] <kierank> I found reference implementation [19:11:06 CEST] <durandal_1707> kierank: so block 2 is also finished and only P frames are left? [19:11:26 CEST] <kierank> I am not doing p-frames [19:11:31 CEST] <kierank> no samples exist for real [19:11:39 CEST] <kierank> and too much mpegvideo mess to integrate 10-bit [19:11:56 CEST] <kierank> don't know about block_type 2 actually [19:12:01 CEST] <kierank> reference implementation doesn't actually follow spec [19:12:43 CEST] <kierank> block[width*(height-1-i)+j] = current [19:12:48 CEST] <kierank> that's what reference implementation does [19:12:55 CEST] <kierank> where j from 0 to width [19:12:58 CEST] <kierank> so it's not right to left at all [19:53:37 CEST] <kierank> durandal_1707: there is still weird dot under the 6, must be idct related [22:11:03 CEST] <durandal_1707> converted all gotos from prosumer decoder [23:06:25 CEST] <durandal_1707> j-b: is my imm4 patch log message ok? [23:06:37 CEST] <j-b> durandal_1707: sorry, I was AFK quite a bit [23:06:46 CEST] <j-b> I'm still catching up with mails [23:15:57 CEST] <j-b> durandal_1707: LGTM [23:16:24 CEST] <j-b> durandal_1707: doesn't this patch require a version bump? [23:16:45 CEST] <j-b> (minor or revision, I don't remember, when adding a CODEC_ID) [23:17:02 CEST] <durandal_1707> j-b: i will add it before pushing [23:19:01 CEST] <atomnuker> I think its a minor bump [23:19:14 CEST] <atomnuker> and put something in the changelog if you haven't [23:20:02 CEST] <j-b> good point [23:20:13 CEST] <j-b> (also, really cool) [23:20:52 CEST] <durandal_1707> j-b: i think there is >100 special CCTV codecs [23:21:00 CEST] <j-b> probable. [23:21:04 CEST] <j-b> Geox crap too [23:27:00 CEST] <j-b> what is prosumer? [23:28:22 CEST] <j-b> ah yes, BT20 [23:30:24 CEST] <durandal_1707> j-b: 1999 era [23:30:48 CEST] <j-b> durandal_1707: tbh, your BT20 is harder to read than your IMM4 one [23:30:53 CEST] <j-b> +code [23:34:38 CEST] <durandal_1707> j-b: yes, because code uses 16bit integers a lot, it can be further simplified too [23:35:26 CEST] <j-b> probably [23:36:23 CEST] <j-b> all the if ((((b >> 8) & 0xFFu) != 0x80u) || (b & 0xFFu)) { and so on [00:00:00 CEST] --- Tue Aug 21 2018

1 0

ffmpeg.log.20180820
by burek 21 Aug '18

21 Aug '18

[01:45:40 CEST] <theemacsshibe> hello everyone [01:46:02 CEST] <theemacsshibe> is there a reverse of image2pipe? i want to make a video into a PBM pipe to feed to a video processor [01:46:23 CEST] <c_14> pretty sure -f pbm_pipe is a thing [01:47:07 CEST] <theemacsshibe> ffmpeg tells me "Requested output format 'pbm_pipe' is not a suitable output format" [01:48:01 CEST] <theemacsshibe> i tried "ffmpeg -i foo.mp4 -f pbm_pipe out.pbms" [01:51:14 CEST] <c_14> -f image2pipe should work in any case [01:51:50 CEST] <theemacsshibe> right [01:58:02 CEST] <theemacsshibe> "ffmpeg -f image2pipe -i foo.mp4 -vcodec pbm out.pbm" is the closest i've gotten to. [01:59:33 CEST] <theemacsshibe> got it [01:59:53 CEST] <theemacsshibe> "ffmpeg -i foo.mp4 -f image2pipe -vcodec pbm out.pbms" [01:59:56 CEST] <theemacsshibe> goodbye [06:26:48 CEST] <hiihiii> ugh [06:27:08 CEST] <hiihiii> I've been using ffmpeg for over a year now [06:27:46 CEST] <hiihiii> stopped using most other video editor or tools out there [06:28:26 CEST] <hiihiii> lately I've been using it on my phone through termux to resize images [06:29:19 CEST] <hiihiii> for uplaod of course, cause the damn thing doesn't ship with an image resizer lol [06:30:29 CEST] <hiihiii> I'm running ffmpeg -i image.jpg -vf "scale=-1:480" -an output.png [06:32:35 CEST] <hiihiii> any image that is not landscape (ie portrait) gets rotated [06:32:47 CEST] <hiihiii> I'm scratching my head now [06:33:40 CEST] <hiihiii> tried using setsar but it did not work [06:43:05 CEST] <furq> hiihiii: weird [06:43:25 CEST] <furq> i assume this is an exif rotation metadata issue, but apparently the default is to just rotate the output accordingly [06:43:38 CEST] <furq> so idk why that's not working [06:43:56 CEST] <furq> you can try -autorotate anyway [06:44:42 CEST] <furq> actually it looks like new ffmpeg only has -autorotate and no -noautorotate, so i guess the docs on the site are outdated [06:44:49 CEST] <furq> so yeah that should be it [06:44:51 CEST] <hiihiii> setdar=if(lt(in_w\,in_h)\,9\,16):if(lt(in_w\,in_h)\,16\,9) [06:44:56 CEST] <furq> yeah don't do that [06:44:58 CEST] <hiihiii> thx a bunch internet [06:45:07 CEST] <furq> lol [06:46:04 CEST] <hiihiii> most of the time when I'm here I just end up answering myself [06:46:29 CEST] <hiihiii> but let me try -autorotate [06:46:44 CEST] <hiihiii> I figured it would be the metadata [06:46:59 CEST] <furq> yeah that used to be the default [06:47:02 CEST] <furq> not sure why that changed [06:47:44 CEST] <furq> bear in mind that'll rotate before scaling, so you'll probably need something smarter than -1:480 [06:48:05 CEST] <hiihiii> does it have arguments? [06:48:16 CEST] <furq> not as far as i can tell [06:51:26 CEST] <hiihiii> it's input option [06:53:14 CEST] <hiihiii> -autorotate gives the same error when applied as an input/output option [06:54:49 CEST] <hiihiii> I have to restart my phone to see the output files hhh samsung you nuts [06:55:25 CEST] <hiihiii> folders do not have a refresh option?! [06:56:24 CEST] <hiihiii> tried -noautorotate just for the hell of it, same issue [06:56:39 CEST] <hiihiii> guess it's time for that dumb condition [07:30:30 CEST] <hiihiii> the condition didn't work [07:31:07 CEST] <hiihiii> I used -map_metadata 0 to copy metadata directly to the output but it didn't work either [07:39:35 CEST] <furq> well png doesn't have exif so yeah [07:39:48 CEST] <furq> if you encode to jpeg that'll probably work but i assume you don't want to do that [07:40:38 CEST] <hiihiii> I did try jpg as output [07:40:53 CEST] <hiihiii> I'm not that dumb [07:40:59 CEST] <hiihiii> lel [07:41:13 CEST] <hiihiii> going to rotate them manually [07:41:16 CEST] <hiihiii> 2018 [07:43:08 CEST] <furq> oh wait is this iOS [07:43:18 CEST] <furq> apparently iOS uses some custom rotate metadata that nothing else supports [07:43:21 CEST] <hiihiii> andriod [07:43:25 CEST] <furq> nvm them [07:43:32 CEST] <furq> n [07:44:18 CEST] <hiihiii> no big deal I the tedious task = 3 photos [10:33:34 CEST] <mijofa_> Is it possible to do HLS encoding, but encode each segment on-demand? That is to somehow get the manifest ahead of time, then only transcode each segment as it's requested [10:34:14 CEST] <JEEB> how would you still have access to the source at the request point? [10:34:35 CEST] <JEEB> with live for example [10:34:58 CEST] <mijofa_> I've tried doing so by manually creating my own manifest, and then using a combination of -ss and -t to set the timing, I've actually managed to get it to work in my web browser (Chrome) but I'm having odd issues with Chromecast [10:35:15 CEST] <mijofa_> JEEB: I'm encoding it into HLS from a static-file on my filesystem [10:35:28 CEST] <JEEB> ok, in that case for VOD you will have the source, yes [10:35:41 CEST] <JEEB> but you will probably want to start using the API and also something that indexes your input [10:37:03 CEST] <mijofa_> For API usage I've only really got experience with Python, but I've not been able to find Python bindings for ffmpeg/libav. :( [10:37:16 CEST] <Mavrik> It sounds like you need a proper streaming server, not just ffmpeg [10:39:52 CEST] <mijofa_> I've not been able to find anything that doesn't expect to have all the pre-encoded segments on the FS, or to at least start transcoding when the stream starts, and then continue sequentially along and hoping the client keeps up with the server's cleanup [10:40:15 CEST] <mijofa_> Or doesn't jump ahead, at which point it just sits there "buffering" until the server catchs up [10:40:57 CEST] <JEEB> well basically it'd be you making an nginx or apache module or so [10:41:07 CEST] <JEEB> in any case the assets need to be first indexed [10:41:15 CEST] <JEEB> and then using that index you can do frame-exact decoding [10:41:41 CEST] <JEEB> also you need to keep in mind that f.ex. for HLS you need to keep the MPEG-TS muxing so that the stream is continuous with all the flags [10:41:50 CEST] <JEEB> otherwise you will get discontinuities [10:43:02 CEST] <mijofa_> Hmmm, ok, that is probably where I'm running into trouble. Chromecast seems to just give up and stop as soon as it downloads the 2nd segment, but if I set the -output_ts_offset to 1 second more than what I think it "should" be, Chromecast kinda continues, but struggles along in weird ways [10:43:30 CEST] <JEEB> yea you will have to not only encode properly but also mux properly [10:43:37 CEST] <mijofa_> Browser just continues along fine, but it's probably smarter than that [10:43:47 CEST] <mijofa_> Or dumber and just playing it sequentially [10:44:07 CEST] <JEEB> also using -ss and -t sounds really problematic. for a proper solution you will need to start using the APIs and having indexing of the input etc [10:45:01 CEST] <mijofa_> Yeah, I figured the -ss and -t was flakey and needed improvement, but didn't seem to be the culprit [10:46:02 CEST] <mijofa_> Ah, ok, maybe is part of the culprit. Running ffprobe on my manually generated segments indicates they're not *exactly* what I gave to -t, which means my math for the -output_ts_offset is wrong, also the math for me next -ss is wrong [10:46:22 CEST] <mijofa_> Even though I said -accurate_seek, hmm, ok, thanks for the info, this helps me narrow things down significantly [11:53:18 CEST] <gryffus> Hello, i have a problem playing some 4k UHD videos on my Samsung UE55MU6172 TV. Is it possible what is the difference between working and non-working videos? Here is comparison of MediaInfo of Working and non working videos: https://i.imgur.com/yu0a1zZ.png . Thanks for any clue. [11:53:35 CEST] <gryffus> *possible to tell me [12:12:48 CEST] <remlap> gryffus: maybe export them a txt and pastebin it? [12:14:12 CEST] <gryffus> remlap: export what? export to who? I am not sure i understand you. [12:15:10 CEST] <remlap> export the mediainfo to a txt file so its easier to read [12:15:30 CEST] <gryffus> Oh, ok, i will try, give me a sec please [12:15:53 CEST] <remlap> im sure the gui does that but not used in years [12:19:41 CEST] <gryffus> remlap: working ones: [12:19:42 CEST] <gryffus> https://paste.opensuse.org/82625931 [12:23:41 CEST] <gryffus> remlap: non-working ones: https://paste.opensuse.org/30794416 [12:26:28 CEST] <remlap> gryffus: that should help someone, have you tried playing them back in mpv? [12:26:37 CEST] <remlap> that handles hdr very well from what I know [12:26:57 CEST] <gryffus> remlap: mpv is able to play it [12:26:59 CEST] <remlap> ah you're already in there [12:27:50 CEST] <remlap> ah so you're trying to use the inbuilt player in the TV? [12:28:07 CEST] <remlap> not passing through hdmi [12:28:22 CEST] <gryffus> remlap: exactly [12:29:06 CEST] <remlap> probably codec support its the AVC one that plays [12:29:30 CEST] <gryffus> remlap: HEVC plays also [12:29:31 CEST] <gryffus> some [12:29:36 CEST] <gryffus> AVC also only some [12:29:38 CEST] <remlap> SDR? [12:30:44 CEST] <gryffus> dunno, is the SDR/HDR info listed in mediainfo output? [12:31:54 CEST] <remlap> could also be Cinavia since but skimming they look like blu-ray rips [12:32:19 CEST] <gryffus> remlap: this one does not play also: https://paste.opensuse.org/44041924 [12:32:34 CEST] <gryffus> AVC [12:32:54 CEST] <remlap> seems to be picky codec support [12:33:58 CEST] <gryffus> well but this last is AVC High(a)L3.1 and 1280 * 720 exactly... what is not standard with that? [12:34:37 CEST] <remlap> tried a different container [12:35:41 CEST] <gryffus> remlap: i am thinking to root the ******* TV and install Kodi or something on it :x [12:36:23 CEST] <remlap> sounds like a plan if its doable, I would [12:36:24 CEST] <gryffus> Or i will have to transcode all the UHD HDR titles, which will be PITA [12:36:33 CEST] <remlap> or get a 4k streaming device from amazon [12:37:27 CEST] <gryffus> remlap: i use minidlna server on my box, but it cannot do transcoding. I will try to find a software solution first [12:38:18 CEST] <remlap> transcoding 4k would be beasty for the best of systems [12:38:21 CEST] <gryffus> remlap: also, the minidlna is streaming via wifi, so more bandwidth-demanding videos are stuttering [12:38:31 CEST] <remlap> I have converted 4K HDR to SDR for a few seconds of video and takes ages [12:38:50 CEST] <gryffus> :( [12:41:01 CEST] <remlap> https://giant.gfycat.com/ImaginativeKeenBrahmanbull.webm not exactly sfw but 4K HEVC HDR to 4K VP9 SDR [12:41:41 CEST] <remlap> one I did as a test because I wanted to learn how it was done [13:15:26 CEST] <Nacht> ll [13:19:59 CEST] <Nacht> Quick question. A PTS should always be later then the corrosponding DTS, correct ? [13:20:39 CEST] <Nacht> Resulting in FFMPEG saying: Invalid timestamps stream=1, pts=2074169040, dts=2074176240, size=33437 [13:26:49 CEST] <termos> av_opt_set(format->priv_data, "hls_flags", "append_list", AV_OPT_SEARCH_CHILDREN); is it correct by me to set it like this? It does not seem to be set [15:00:32 CEST] <kepstin> Nacht: pts=dts is fine. What container/format is that? [15:04:08 CEST] <Nacht> It's MPEG-TS [15:06:03 CEST] <kerio> Nacht: wait, why [15:06:11 CEST] <kerio> surely there's going to be some reordering [15:06:45 CEST] <DHE> depends on the codecs and settings. keyframes will have pts==dts [15:06:49 CEST] <kerio> if frames 1 2 3 are to be decoded in order 1 3 2 then frame with pts 2 will have a dts of 3 [15:16:28 CEST] <kepstin> oh, wait, i didn't look close enough at that. that is definitely pts < dts [15:16:32 CEST] <kepstin> which is a problem [15:17:37 CEST] <JEEB> I know some HLS streams will have that because people thought it was OK because Apple made some lolbroken files [15:17:43 CEST] <JEEB> there's some funky logic in many JS HLS players for that [15:18:10 CEST] <JEEB> (it seems like MOV/MP4 negative CTS offset timestamps got muxed as-is by apple into MPEG-TS, where they're invalid) [15:18:40 CEST] <JEEB> I have reported such stupidity to at least one vendor, and got a lolbroken Apple sample as a response together with "will not fix" [15:18:46 CEST] <JEEB> "it's OK because apple is doing it" [15:38:47 CEST] <Nacht> The TS itself plays lovely on VLC, but the moment I convert it to MP4 it just stutters franticly [15:39:05 CEST] <Nacht> Which isn't that weird if all the PTS and DTS go all over the palce [15:39:36 CEST] <Nacht> It's like Apple excists solely to screw around everything basic there is the be found in the video world ;/ [15:53:30 CEST] <ozette> isn't ts used for streaming? [15:54:13 CEST] <Nacht> Yes [16:10:55 CEST] <ozette> i feel like it's an end product and shouldn't be converted again [23:59:03 CEST] <barhom> Hey, anyone know anything about the dash muxer? I am using fmp4 with HLS, but afaik I should be able to create dash mpd's out of the same segments. Can I do that with 1 ffmpeg command? [00:00:00 CEST] --- Tue Aug 21 2018

1 0

ffmpeg-devel.log.20180819
by burek 20 Aug '18

20 Aug '18

[00:32:11 CEST] <kierank> michaelni: is raw mpeg4video actually supported [00:34:36 CEST] <kierank> what does this mean [00:34:37 CEST] <kierank> [mpeg4 @ 0x2f49a40] slice end not reached but screenspace end (2 left 000000, score= -28) [00:55:32 CEST] <jamrial> kierank: that log error goes as back as 2003. end decode_slice() in h263dec.c [00:55:45 CEST] <jamrial> some padding thing? [00:55:48 CEST] <kierank> I know where's it's from but it of course makes no sense [00:55:59 CEST] <jamrial> christ, this function depends 50% on workaround_bugs logic [01:00:52 CEST] <kierank> problem is I don't know which samples are intra [01:13:06 CEST] <michaelni> kierank, mpeg4-es (if i call it that way) is supported [01:13:46 CEST] <kierank> well the reference samples don't decode [01:13:48 CEST] <kierank> for some reason [01:13:53 CEST] <kierank> but the ones I have do [01:13:57 CEST] <michaelni> thats odd [01:15:08 CEST] <kierank> the samples I have are mxf [01:15:34 CEST] <kierank> http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_14496-4_20… [01:17:31 CEST] <kierank> [mpeg4 @ 0x2765440] slice end not reached but screenspace end (1 left 000000, score= -58) [01:17:34 CEST] <kierank> that's the only error [01:25:51 CEST] <michaelni> ahh these are studio profile, which of them is suppsoed to work ? many seem to use unsupported features like DPCM [01:30:10 CEST] <kierank> the first frame of them are normal I frames [01:30:22 CEST] <kierank> I'm trying to test my dpcm code now [01:40:49 CEST] <michaelni> kierank, i think studio profile doesnt do the same padding that the other profiles do at the end of slices. This could trigger "slice end not reached..." i think [01:42:30 CEST] <kierank> great, I have to now understand the messiest code in lavc [01:45:52 CEST] <kierank> there might be assumptions in studio mode that 1 mb per slice [01:53:05 CEST] <michaelni> i think you only need to return SLICE_END at the end of slices, especially the end of the last slice [01:53:45 CEST] <michaelni> i have no testcase so iam guessing but the only code i see returning SLICE_END in studio profile requires 24 more bits [01:54:14 CEST] <michaelni> maybe studio profile allows the last slice to end with less [01:55:17 CEST] <michaelni> non studio doesnt require this [01:57:50 CEST] <kierank> michaelni: eh? [01:58:30 CEST] <kierank> do { [01:58:30 CEST] <kierank> StudioMacroblock() [01:58:30 CEST] <kierank> } while ( next_bits() != 000 0000 0000 0000 0000 0000 ) [01:58:30 CEST] <kierank> next_start_code_studio() [01:58:38 CEST] <kierank> so 23 bits of zero is end of slicec [02:00:00 CEST] <michaelni> this is maybe true if you consider a file to be a single bitstream but maybe is not once it is split into frames [02:05:30 CEST] <kierank> the predictor stuff might not work with multiple macroblocks per slice [02:48:03 CEST] <cone-026> ffmpeg 03Michael Niedermayer 07master:46753bfdd018: avformat/dashdec: Fix strlen(rep_id_val) with it being NULL [03:19:45 CEST] <kierank> michaelni: sorry I don't see what the issue is with the current code [03:19:48 CEST] <kierank> it retuns at end of slice [03:23:42 CEST] <kierank> michaelni: nobody can understand that magic padding code [04:00:53 CEST] <cone-026> ffmpeg 03Ronak Patel 07master:223d2bde22ce: Improve hls VOD mode hls performance problem. [04:43:39 CEST] <cone-026> ffmpeg 03James Almer 07master:de1b44c20604: avformat/matroskaenc: handle AV1 extradata in packet side data [09:26:45 CEST] <Compn> is it emu edge, h264 cropping, or something else hmmm [09:27:06 CEST] <Compn> i remember emu edge was a difficult thing back when h264 was new [09:46:23 CEST] <gagandeepsingh> kierank:for that check everything will work if we keep check only on s->a_width, s->a_height, s->a_format [09:46:40 CEST] <gagandeepsingh> and remove check on s->coded_width, s->coded_height [09:47:01 CEST] <gagandeepsingh> as s->a_width is set using s->coded_width during buffer allocations [09:47:20 CEST] <gagandeepsingh> and later you set s->coded_width = 0 [09:47:52 CEST] <gagandeepsingh> and error is given when s->coded_width is non zero [14:46:54 CEST] <kierank> michaelni: testing your patch, thanks [15:08:27 CEST] <kierank> michaelni: did you actually get the first frame out? [15:22:20 CEST] <kierank> ok on some samples I do [16:01:39 CEST] <durandal_1707> kierank: where are you stuck? [16:02:01 CEST] <kierank> can't get some blocks to look right [16:02:24 CEST] <kierank> also chroma blocks can be wrong when same luma block is right [16:02:26 CEST] <durandal_1707> so bitparsing is 100% working? [16:02:39 CEST] <kierank> yes bitparsing is good for iframes I think with michaelni code to find slice end [16:03:36 CEST] <durandal_1707> kierank: you pushed wip code somewhere? [16:03:40 CEST] <kierank> I maybe got rice code wrong I guess [16:05:37 CEST] <kierank> durandal_1707: https://github.com/kierank/ffmpeg-sstp [16:05:42 CEST] <durandal_1707> you could add bunch of printfs to find what kind of blocks have artifacts [16:05:52 CEST] <kierank> ffmpeg -loglevel debug -threads 1 -i vcon-stp11L1.bits -threads 1 -ss 0.04 -f rawvideo -y out.yuv [16:06:01 CEST] <kierank> I can't [16:06:07 CEST] <kierank> it's all i-blocks [16:08:10 CEST] <atomnuker> durandal_1707: I got some mad fft code working, can't believe it works [16:08:36 CEST] <atomnuker> supports floats and doubles and wraps complex.h if its there, otherwise does things manually with a macro [16:09:58 CEST] <atomnuker> right now I've ported mdct15, just needs the ptwo fft to work as it did before [16:10:40 CEST] <atomnuker> for some reason the ptwo fft uses doubles in some internal calculations but outputs floats [16:12:12 CEST] <atomnuker> hopefully the asm doesn't, but if it doesn't that means there'll be a precision mismatch between c and asm and that's not good (more so than if you used fma occasionally) [16:14:51 CEST] <durandal11707> kierank: so y plane is always correct? your program cant extract Y plane? mpv can [16:15:02 CEST] <kierank> y plane is mostly correct [16:15:51 CEST] <kierank> weird because y looks ok cb bad cr good [16:15:52 CEST] <durandal11707> each macroblock have own sync code? [16:15:58 CEST] <kierank> no [16:16:04 CEST] <kierank> it has slices with n macroblocks [16:16:22 CEST] <durandal11707> and with custom positions? [16:16:53 CEST] <kierank> I think linear [16:17:02 CEST] <kierank> custom mode and scan order [16:21:21 CEST] <durandal11707> this T L TL prediction is strange [16:22:36 CEST] <durandal11707> why is rice parameter 15 becoming 0 ? [16:23:21 CEST] <kierank> rice_parameter: This is an unsigned integer that indicates the length of the rice_suffix_code field. The value 0 is [16:23:21 CEST] <kierank> forbidden. The value 15 shall be interpreted as 0. [16:24:01 CEST] <kierank> i suspect a mistake in prediction code [16:28:06 CEST] <durandal11707> kierank: is that sample triggering block_type == 2? [16:28:14 CEST] <kierank> yes [16:28:26 CEST] <durandal11707> well, it is wrong [16:28:43 CEST] <kierank> I am trying to set block_type 2 to black [16:28:45 CEST] <kierank> but it's not working [16:28:51 CEST] <kierank> so I have a stride error I guess [16:28:55 CEST] <kierank> durandal11707: how? [16:30:02 CEST] <durandal11707> kierank: it starts from w to >0 but it should be w-1 to >=0 [16:31:57 CEST] <kierank> hmmm [16:32:01 CEST] <kierank> yes true [16:35:16 CEST] <kierank> durandal11707: not any better [16:38:17 CEST] <durandal11707> you changed dest_pcm[i] too? [16:38:50 CEST] <kierank> durandal11707: to do what [16:39:37 CEST] <durandal11707> you can not make it to point to the end [16:39:37 CEST] <kierank> afaik that's indexed correctly [16:40:17 CEST] <kierank> already done I think [16:40:24 CEST] <kierank> dest_pcm[i] += (linesize[i] / 2) * (16 >> vsub); [16:40:31 CEST] <kierank> points to beginning of last row [16:41:17 CEST] <kierank> just rewrote block_type=1 to black [16:41:24 CEST] <kierank> no artefacts so must be block_type=1 broken [16:41:49 CEST] <durandal11707> ((16 >> vsub) - 1) [16:42:21 CEST] <kierank> yes true [16:42:47 CEST] <kierank> god this reverse scan is confusing [16:45:55 CEST] <kierank> ah get_bits(gb, 0 is forbidden) [16:46:04 CEST] <durandal11707> yea [16:46:58 CEST] <durandal11707> get_bitsz [16:47:24 CEST] <kierank> ah there is function for this [16:49:46 CEST] <durandal11707> atomnuker: you can use doubles in asm too i think [16:50:03 CEST] <kierank> ah yes get_bitsz removes lots of artefacts [16:51:08 CEST] <kierank> https://twitter.com/kierank_/status/1031191813858779136 [16:55:38 CEST] <kierank> block_type=2 still does nothing [16:56:03 CEST] <kierank> I set to green (0x0 value) and still comes out black [16:57:01 CEST] <atomnuker> durandal11707: yeah, but you have to truncate at some point, and whatever you do you halve throughput and have to pay the price for splitting registers [16:57:17 CEST] <atomnuker> doesn't seem it would be worth it, so I'd rather have the float fft be fully float [17:02:03 CEST] <kierank> durandal11707: bah, so close [17:04:57 CEST] <durandal11707> kierank: it doesnt makes sense to be always black no matter what you set it to [17:05:05 CEST] <kierank> yes [17:05:20 CEST] Action: kierank looking at reference decoder source [17:05:25 CEST] <kierank> 200MB of code [17:08:00 CEST] <kierank> yeah doesn't have right things [17:13:55 CEST] <durandal11707> perhaps prediction goes nuts and it sets everthying to negative numbers and that it is black? u/v should be black too [17:14:28 CEST] <durandal11707> * u/v shouldn't [17:15:20 CEST] <kierank> gonna printf some pixel values [17:16:13 CEST] <durandal11707> exact output values? there is datascope filter for that [17:18:46 CEST] <kierank> actually I think I know what hte problem is [17:20:26 CEST] <kierank> I don't fully understand the predictor reset rules [17:23:12 CEST] <kierank> actually it's not block_type=2 at the moment [17:23:21 CEST] <kierank> crap [17:36:54 CEST] <durandal11707> kierank: post screenshot of page where predictor rules are [17:37:07 CEST] <kierank> i think bug might be clipping [17:37:31 CEST] <kierank> clipping gives small improvement [17:39:24 CEST] <kierank> this could be ffmpeg but with idct actually [17:39:27 CEST] <kierank> values are not clipped correctly [17:40:37 CEST] <kierank> michaelni: does ffmpeg not clip output of idct as per mpeg-4 specification? [17:40:46 CEST] <kierank> between 0 and 2^(bit_depth) - 1 [17:48:37 CEST] <kierank> durandal11707: gonna give up [17:49:08 CEST] <durandal11707> kierank: push your latest changes to github [17:49:16 CEST] <kierank> I will [17:49:36 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/gNg3sb6e/image.png [17:49:45 CEST] <durandal11707> kierank: so block type 2 is not triggered at all? [17:50:08 CEST] <kierank> not when i force single frame decode [17:50:09 CEST] <kierank> ffmpeg -loglevel debug -threads 1 -i vcon-stp11L1.bits -threads 1 -frames 1 -f rawvideo -y out.yuv [17:51:35 CEST] <durandal11707> ugh, that doesnt make sense [17:52:35 CEST] <kierank> sample may have unsupported features i guess [17:55:39 CEST] <durandal11707> Here is my working BT20 decoder: https://github.com/richardpl/FFmpeg/blob/bt20/libavcodec/prosumer.c feel free to clean it up [18:46:17 CEST] <kierank> durandal11707: I dunno what else to do [18:56:01 CEST] <durandal11707> kierank: take a little break, then tomorrow try again :) [19:00:09 CEST] <kierank> Got work tomorriw [19:01:08 CEST] <durandal11707> quit job [19:03:45 CEST] <durandal11707> hire someone to do it! [19:34:10 CEST] <durandal11707> j-b: are you there? [20:16:32 CEST] <kierank> durandal11707: hmm so it definitely on a rice code block [20:42:04 CEST] <durandal11707> kierank: there are other blocks? [20:42:16 CEST] <kierank> yes normal idct block [20:42:30 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/911nrluQ/image.png [20:42:32 CEST] <kierank> rice blocks set to black [20:44:02 CEST] <durandal11707> so only some rice blocks do not decode properly [20:45:01 CEST] <kierank> yeah [20:45:09 CEST] <kierank> depends on component [20:49:08 CEST] <kierank> I think related to bizzare mpegvideo.c code [20:49:24 CEST] <kierank> chroma blocks are stored in crazy way [20:49:51 CEST] <durandal11707> ? so if you set chroma to 0 it is not green? [20:50:17 CEST] <kierank> dunno [20:50:23 CEST] <kierank> not sure any more [20:51:02 CEST] <kierank> actually some luma is screwed too [20:52:42 CEST] <durandal11707> kierank: perhaps parsing is source of that, the slice end finding looks strange [20:52:50 CEST] <kierank> maybe [20:53:01 CEST] <kierank> but that code is totally impossible to understand [20:53:02 CEST] <durandal11707> check for underreads and for overreadds [20:53:05 CEST] <kierank> michaelni: magic [20:53:10 CEST] <kierank> michaelni magic [20:54:16 CEST] <durandal11707> if single macroblock in slice is broken than all rest of slice should be too, if parsing is buggy [20:55:50 CEST] <kierank> yeah i think parsing screwed [20:56:57 CEST] <kierank> michaelni: do you know what was special with vcon-stp10L1.bits [20:57:32 CEST] <kierank> vcon-stp11L1.bits i mean [20:58:15 CEST] <kierank> seems like ffmpeg has read the right size [22:09:21 CEST] <michaelni> kierank, about idct, the put/add idct stuff clips as required, it has to. about vcon-stp11L1.bits, without looking into it i have no idea at all [22:10:34 CEST] <kierank> Ok [22:10:41 CEST] <kierank> It was the only one that you didn't comment [22:10:56 CEST] <kierank> Seems to be the only one FFmpeg can decode as well [22:12:35 CEST] <michaelni> the comments are based on testing with abort(), if its not mentioned it triggered neither codepath or i missed it [22:15:23 CEST] <michaelni> the 11L1 one doesnt seem to decode slices till their end with git master thats probably why it didnt trigger either end detection [22:36:50 CEST] <kierank> I don't understand what is wrong [22:42:28 CEST] <kierank> Amendment 1 (Studio Profile) [22:42:28 CEST] <kierank> Actually, there is no available implementation to this amendment regarding to MS version of reference software. It requires some volunteer to take responsible for this part if possible. [22:42:29 CEST] <kierank> ffs [22:53:36 CEST] <kierank> % Modulus operator. Defined only for positive numbers [22:53:40 CEST] <kierank> hmmm could be why [00:00:00 CEST] --- Mon Aug 20 2018

1 0

ffmpeg.log.20180819
by burek 20 Aug '18

20 Aug '18

[00:08:14 CEST] <anden> well, just me overestimating my ability to solve this issue when my brain is really too tired for it. thanks for the help guys. i'll continue after i had some sleep [00:09:36 CEST] <Cracki> mystery remains [01:26:01 CEST] <qxt> what is the most supported format in browsers for video and audio? Thinking about using ffmpeg to transcode video on nextcloud servers for streaming. [01:26:29 CEST] <qxt> kinda silly that I have to download a video to watch it imo [01:26:39 CEST] <qxt> webm? [01:41:30 CEST] <furq> qxt: h264/aac in mp4 is universal [01:41:39 CEST] <furq> webm isn't supported by apple and probably won't be [01:43:47 CEST] <qxt> thx furq. [13:48:17 CEST] <kerio> thank fuck for the iphone [13:48:23 CEST] <kerio> or safari on macos would be left behind [13:48:25 CEST] <kerio> :3 [19:50:11 CEST] <ePirat> How do I correctly do 2-pass processing in ffmpeg? [19:50:46 CEST] <JEEB> depends on what you're doing. various video encoders take in -pass 1/2/x [19:50:56 CEST] <ePirat> ffmpeg -i .\file.wmv -pass 1 -af loudnorm=I=-13:TP=-1 -c:v prores -c:a pcm_s16le -f mov NUL [19:50:58 CEST] <ePirat> is what I did [19:51:19 CEST] <ePirat> and then a second pass after this [19:51:34 CEST] <JEEB> so which thing are you trying to 2pass? [19:51:38 CEST] <JEEB> the filter or the video encoder? [19:51:42 CEST] <ePirat> the filter [19:51:45 CEST] <JEEB> ok [19:51:52 CEST] <JEEB> then it's specific to the filter [19:52:19 CEST] <JEEB> and you wouldn't have to do anything for the video [19:52:56 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#loudnorm [19:53:19 CEST] <JEEB> I don't see anything regarding it saving 1st pass data. just stats which are printed, even [19:54:34 CEST] <ePirat> JEEB, well the description has "double pass (files) modes" so I assumed it would "just work" with the 2-pass stuff& [19:54:36 CEST] <ePirat> thats a bit confusing [19:55:23 CEST] <JEEB> the "pass" option is an AVOption I think, and I don't think avfilters get those passed on from the cli, so the options have to be given to the lavfi filter's parameters specifically [19:55:33 CEST] <JEEB> and the -pass 1/2/x options become irrelevant [19:55:46 CEST] <ePirat> so I need to do the first pass, with print_format and then for the second provide data for measured_* stuff out of the json? [19:55:50 CEST] <JEEB> and yea it says it supports both modes [19:55:54 CEST] <JEEB> whatever that means [19:56:04 CEST] <JEEB> since the document only mentions that stats thing, which goes to stdout? [19:56:30 CEST] <JEEB> (also no examples mentioned in docs) [19:57:34 CEST] <JEEB> yea the code has no mention of 2pass or anything, just the stats [19:57:35 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/af_loudnorm.c;h=… [19:58:08 CEST] <JEEB> so I guess it's a case of "parse that crap and set values accordingly" [19:58:26 CEST] <ePirat> great :p [19:59:07 CEST] <ePirat> JEEB, thanks for your help. should I submit a patch to improve the documentation about that? [19:59:17 CEST] <JEEB> if you could be so kind that'd be nice [19:59:24 CEST] <JEEB> if you notice what I mentioned actually works [20:32:46 CEST] <ePirat> JEEB, can I somehow make ffmpeg just process the filter? I just tried to copy codec but I get: Filtergraph 'loudnorm=I=-13:TP=-1:print_format=summary' was defined for audio output stream 0:1 but codec copy was selected. [20:33:34 CEST] <JEEB> ffmpeg -i blah -map 0:a -af blah -f null - [20:33:38 CEST] <JEEB> is how I usually do it [20:52:29 CEST] <ePirat> JEEB, it seems to work when providing it with the needed information. [20:53:40 CEST] <JEEB> alright [22:48:52 CEST] <the_fluffybread> hello [22:49:01 CEST] <the_fluffybread> could i tell ffmpeg to output data according to an sdp file [22:49:14 CEST] <the_fluffybread> rtp, specifically [23:25:04 CEST] <Cracki> what did you google for? [23:33:24 CEST] <the_fluffybread> "ffmpeg output to sdp" returns a bunch of stackoverflow question about recieving input with an sdp file [23:50:28 CEST] <c_14> the_fluffybread: yes [23:50:37 CEST] <c_14> use the rtp output with -write_sdp_file or something [23:50:52 CEST] <c_14> -sdp_file [23:51:29 CEST] <the_fluffybread> yeah but that prints sdp [23:51:32 CEST] <the_fluffybread> i'm making a voip app [23:51:56 CEST] <the_fluffybread> and it would be great if ffmpeg could automatically adapt to the sdp file it receives from the remote host [23:52:14 CEST] <c_14> nah [23:52:17 CEST] <c_14> It can't do that [23:52:25 CEST] <c_14> You can do it with the libraries, but not with the cmd app [00:00:00 CEST] --- Mon Aug 20 2018

1 0

ffmpeg-devel.log.20180818
by burek 19 Aug '18

19 Aug '18

[01:57:01 CEST] <BBB> jamrial: hey, have you decided to come to VDD? [02:03:04 CEST] <jamrial> BBB: i'll probably pass this year, sorry [02:06:21 CEST] <atomnuker> you pass every year :( [02:10:21 CEST] <BBB> awh :( please please please? [02:10:29 CEST] <BBB> we really need more normal people to show up [02:10:44 CEST] <BBB> at some point people will think we (ffmpeg) are just one big freakfest [02:11:10 CEST] <BBB> youre probably the most normal person in our community, please please please come [11:17:46 CEST] <cone-481> ffmpeg 03Jun Zhao 07master:d428ef0ea584: lavf/network: add a ff_log_net_error function. [11:17:46 CEST] <cone-481> ffmpeg 03Jun Zhao 07master:0a8ff1d8bb07: lavf/network: check return value of setsockopt. [11:17:46 CEST] <cone-481> ffmpeg 03Jun Zhao 07master:0ed0af595b69: lavf/tcp: check return value of setsockopt. [11:17:46 CEST] <cone-481> ffmpeg 03Jun Zhao 07master:49efd41c4717: lavf/udp: use ff_log_net_error to replace log_net_error [12:37:31 CEST] <akravchenko188> Hi, guys. could you please help me. I have sent patch month ago, I have put couple of reminders here and in forum, no answer [12:38:51 CEST] <JEEB> feel free to find your patch on patchwork (if you sent it to the mailing list) and both link it here as well as ping the patch on the mailing list https://patchwork.ffmpeg.org/project/ffmpeg/list/ [12:43:38 CEST] <akravchenko188> Thanks, I have already sent reminder in maillist [12:45:09 CEST] <akravchenko188> reminder: could you please review the patch 1: https://patchwork.ffmpeg.org/patch/9663/ [12:46:07 CEST] <akravchenko188> reminder: could you please review the patch 2: https://patchwork.ffmpeg.org/patch/9662/ [12:46:35 CEST] <akravchenko188> thanks [16:40:27 CEST] <cone-766> ffmpeg 03PaweB Wegner 07master:85c00643b763: avformat/tls_schannel: Fix use of uninitialized variable [18:30:31 CEST] <durandal_1707> j-b: have you looked at last patch for IMM4, is log message ok for you? [19:10:02 CEST] <kierank> durandal_1707: going to RE that canon codec? [19:12:26 CEST] <durandal_1707> kierank: canon? [19:12:35 CEST] <kierank> cr3 or wahtever it called [19:12:44 CEST] <kierank> https://github.com/lclevy/canon_cr3 [19:13:15 CEST] <durandal_1707> ah, only if guy pay me, i'm pro now [19:18:29 CEST] <gagandeepsingh> michaelni: what do i need to perform fuzzing? [19:21:10 CEST] <kierank> I think you should commit (good) changes and let google fuzz it [19:21:32 CEST] <kierank> michaelni: just give gagandeepsingh access to the cfhd crashes [19:23:31 CEST] <Compn> gagandeepsingh : zzuf program, sample file and ffmpeg [19:24:06 CEST] <durandal_1707> american fuzzy loop for advanced fuzzers [19:25:18 CEST] <michaelni> gagandeepsingh, what compn and durandal_1707 said. thx btw [19:26:46 CEST] <jamrial> wow, there really exists a fuzzer called "american fuzzy lop" [19:27:22 CEST] <JEEB> yup [19:27:25 CEST] <JEEB> AFL [19:27:47 CEST] <gagandeepsingh> thanks [19:28:16 CEST] <durandal_1707> but that would be very hard for big files to get fuzzed with AFL [19:28:53 CEST] <durandal_1707> so just leave it to google machines? [19:29:29 CEST] <durandal_1707> unless you can already spot possible security relevant bugs/problems [19:31:30 CEST] <durandal_1707> gagandeepsingh: does github cineform have code to handle IP encoding? [19:32:11 CEST] <gagandeepsingh> durandal_1707: i haven't looked at encoder.c currently [19:32:24 CEST] <gagandeepsingh> it has all the functions to perform the transforms though [19:34:25 CEST] <kierank> michaelni: why won't you just let him commit and make google do the fuzzing [19:34:35 CEST] <kierank> and then send him the crashes and he fix them [19:37:31 CEST] <durandal_1707> anybody with commit bit can already push cfhd patches [19:39:02 CEST] <kierank> one of them needs some work [19:48:42 CEST] <Compn> durandal_1707 : have to mark cfhd as experimental :P [19:49:29 CEST] <durandal_1707> Compn: i could tell you something nasty [19:51:00 CEST] <atomnuker> we don't mark decoders as experimental [19:54:25 CEST] <kierank> gagandeepsingh: if you make good fix for #if0 I will push 1/2 [19:55:31 CEST] <jamrial> speaking of cfhd, the current code has data races [19:55:50 CEST] <durandal_1707> where? [19:55:57 CEST] <jamrial> http://fate.ffmpeg.org/report.cgi?time=20180818110226&slot=x86_64-archlinux… [19:56:26 CEST] <jamrial> alloc_buffers() called from cfhd_decode() [19:58:37 CEST] <jamrial> ff_set_dimensions() called from that function, to be precise [19:58:56 CEST] <kierank> gagandeepsingh: can you look at that ^ [20:00:46 CEST] <kierank> gagandeepsingh: [20:00:46 CEST] <kierank> 6:55:30 PM <"jamrial> speaking of cfhd, the current code has data races [20:00:46 CEST] <kierank> 6:55:49 PM <"durandal_1707> where? [20:00:46 CEST] <kierank> 6:55:57 PM <"jamrial> http://fate.ffmpeg.org/report.cgi?time=20180818110226&slot=x86_64-archlinux… [20:00:46 CEST] <kierank> 6:56:25 PM <"jamrial> alloc_buffers() called from cfhd_decode() [20:00:46 CEST] <kierank> 6:58:37 PM <"jamrial> ff_set_dimensions() called from that function, to be precise [20:00:47 CEST] <kierank> 6:58:55 PM <"kierank> gagandeepsingh: can you look at that ^ [20:01:25 CEST] <gagandeepsingh> kierank: alright [20:03:18 CEST] <gagandeepsingh> kierank: data races, are they for the existing code or the code in my patch? [20:03:25 CEST] <kierank> existing code [20:03:35 CEST] <gagandeepsingh> ok, will help pinpointing stuff [20:07:00 CEST] <gagandeepsingh> kierank: just wondering, that check in place, if i had to work around that check, wouldn't that defeat the purpose? [20:07:15 CEST] <kierank> gagandeepsingh: ? [20:07:16 CEST] <kierank> check in place [20:07:21 CEST] <gagandeepsingh> #if 0 [20:07:37 CEST] <kierank> you need to submit working code without that [20:08:04 CEST] <gagandeepsingh> i had to disable it because it was checking image width and height, but mountain sample does not bring that info before the check executes [20:08:27 CEST] <kierank> strange, where does it do the check [20:08:34 CEST] <kierank> where does it signal width and height [20:09:09 CEST] <kierank> how can it code width and height *after* end of header tag [20:09:20 CEST] <gagandeepsingh> since s->coded_width is set form the image width tag, it was zero, and then for allocating buffers one needs non zero s->coded_width initially [20:09:36 CEST] <kierank> it must use another tag then [20:09:40 CEST] <gagandeepsingh> so i had to give s->coded_width from s->lowpass_width dat [20:09:56 CEST] <gagandeepsingh> the image tag is in next packet, the empty packet [20:09:57 CEST] <kierank> it's weird though, official decoder must have same problem [20:10:24 CEST] <gagandeepsingh> all other samples correctly bring it though in the first packet [20:10:57 CEST] <kierank> you could make a check for if(coded_width == 0) allocate buffers elswhere [20:11:03 CEST] <kierank> a bit of a hard problem [20:12:10 CEST] <kierank> do we have a "fate with big samples"? [20:12:49 CEST] <kierank> I guess mountain sample can be cut [20:13:07 CEST] <gagandeepsingh> yeah, cut without re-encode [20:13:21 CEST] <kierank> mountain sample should be in fate [20:13:26 CEST] <kierank> at least first few frames [20:14:09 CEST] <gagandeepsingh> again i also have bit exact samples, will cut and ask how to add in fate [20:14:30 CEST] <kierank> michaelni: can you add gagandeepsingh samples to fate? [20:14:56 CEST] <durandal_1707> kierank: first need to be uploaded somewhere [20:15:12 CEST] <kierank> gagandeepsingh: send michaelni samples with wetransfer [20:15:14 CEST] <kierank> or 0x0.st [20:15:33 CEST] <gagandeepsingh> after cut right? [20:15:43 CEST] <kierank> small ones are ok [20:15:48 CEST] <kierank> but mountain sample needs cut [20:15:50 CEST] <kierank> it's big if i remember [20:15:52 CEST] <gagandeepsingh> i have no small ones [20:16:09 CEST] <michaelni> kierank, yes, i can but probably later [20:16:09 CEST] <gagandeepsingh> mine are above full hds for 20seconds [20:16:20 CEST] <kierank> https://github.com/gopro/cineform-sdk/tree/master/Example/videos [20:16:25 CEST] <kierank> what about those as well? [20:17:22 CEST] <kierank> wow people use virtualdub [20:17:27 CEST] <kierank> I used that like 15 years ago [20:18:19 CEST] <gagandeepsingh> they both are intra only [20:18:27 CEST] <kierank> ok [20:18:30 CEST] <kierank> but they are quite small [20:18:33 CEST] <kierank> could be useful still [20:18:42 CEST] <gagandeepsingh> i got no problem [20:21:53 CEST] <kierank> I had a big repository of samples but I can't find it any more [20:22:35 CEST] <kierank> actually I found them [20:22:38 CEST] <kierank> gagandeepsingh: let me email them [20:24:29 CEST] <kierank> gagandeepsingh: I pmmed you samples [20:27:18 CEST] <gagandeepsingh> kierank: where? [20:27:24 CEST] <kierank> gagandeepsingh: PM [20:27:46 CEST] <gagandeepsingh> got them [20:28:02 CEST] <kierank> some quite small ones in there [20:28:05 CEST] <kierank> lots of features tested [20:43:00 CEST] <kierank> durandal_1707: do you have 14496-4 [20:44:01 CEST] <durandal_1707> kierank: what is that? [20:44:10 CEST] <kierank> spec [20:44:22 CEST] <durandal_1707> about what? [20:44:46 CEST] <kierank> mpeg-4 conformance [20:44:51 CEST] <kierank> it explains what features the bitstream samples use [20:45:12 CEST] <durandal_1707> nope, mail me [20:46:13 CEST] <kierank> actually I got it [20:49:34 CEST] <kierank> ffs [20:51:03 CEST] <kierank> not got what i need [20:55:21 CEST] <durandal_1707> kierank: why you need it? [20:55:33 CEST] <kierank> I want to know what features are in each file [20:55:34 CEST] <kierank> http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_14496-4_20… [20:59:46 CEST] <kierank> samples are interesting, they use DPCM mode which I will have to hack into ffmpeg mpegvideo masterpiece [21:00:10 CEST] <atomnuker> there's a 20 page preview here https://www.sis.se/api/document/preview/617424/ [21:00:56 CEST] <kierank> that's the 2000 edition anyway [21:00:59 CEST] <kierank> so it's old [21:02:10 CEST] <JEEB> yeh [21:05:19 CEST] <atomnuker> kierank: you did check the dropbox first, right? [21:05:46 CEST] <kierank> sure, since it's my dropbox [21:06:19 CEST] <atomnuker> kierank: found it [21:06:21 CEST] <atomnuker> https://manualzz.com/doc/29217911/iso-iec-14496-4 [21:06:27 CEST] <kierank> doesn't have what i need [21:06:30 CEST] <kierank> already have that [21:06:33 CEST] <atomnuker> :/ [21:06:56 CEST] <durandal_1707> i need non-power of 2 mdct/fft, filters and decoders depends on you! [21:06:57 CEST] <atomnuker> funnily its listed under "baby & children toys & accessories toy parts ISO/IEC 14496-4" [21:11:42 CEST] <kierank> finally found samples with dpcm coding so I can implement this tonight [21:13:33 CEST] <kierank> dpcm_scan_order: This is a flag that indicates the scanning order of blocks for DPCM coding. If set to value 0 [21:13:33 CEST] <kierank> the block is scanned from top line to bottom line, and from left to right. If set to value 1 the block is scanned from [21:13:33 CEST] <kierank> bottom line to top line, and from right to left. [21:13:34 CEST] <kierank> insane [21:15:29 CEST] <JEEB> wow, so they even reversed the order horizontally [21:16:00 CEST] <durandal_1707> who is running this persistent and pointless, resource wasting spamming? [21:16:28 CEST] <kierank> JEEB: yeah it's an insane mode to check [21:20:15 CEST] <atomnuker> why did they implement something like that? the hardware people wouldn't have been happy [21:21:53 CEST] <kierank> atomnuker: it's delta coding so theoretically top left part of block could have nothing [21:21:56 CEST] <kierank> and bottom right could [21:22:05 CEST] <kierank> (but then why the encoder would choose pcm) [21:22:35 CEST] <kierank> I really hope none of the samples have that weird system [21:22:47 CEST] <durandal_1707> it was someone's job [21:28:13 CEST] <atomnuker> mpeg4 is kinda rare to see nowadays, no one distributes xvid encodings anymore and outside of that it was only viable for a short amount of time before h264 [21:28:34 CEST] <kierank> sure but in 100 years I want random fields to be decodable [21:28:41 CEST] <kierank> long before the binary blobs needed are gone [21:30:13 CEST] <JEEB> atomnuker: I've seen it in the weirdest places still used [21:30:49 CEST] <durandal_1707> atomnuker: please tell me you are working on new mdct/fft [21:31:19 CEST] <kierank> durandal_1707: [21:31:20 CEST] <kierank> 8:06:56 PM <"durandal_1707> i need non-power of 2 mdct/fft, filters and decoders depends on you! [21:31:22 CEST] <atomnuker> JEEB: where? it was never (afaik) used in broadcasting apart from consumer decoders which isn't pro [21:31:23 CEST] <kierank> what do you use that for? [21:31:40 CEST] <atomnuker> a filter (I think) and the siren codec (I think) [21:31:51 CEST] <durandal_1707> bm3d filter [21:32:02 CEST] <JEEB> atomnuker: internal stuff in certain places. I double-blinked when I saw the stream contained MPEG-4 Part 2 [21:32:16 CEST] <durandal_1707> vivo siren for Compn's porn [21:32:46 CEST] <atomnuker> that non-keyframe codec? lol, I tried to find some samples of that today and couldnt [21:33:40 CEST] <atomnuker> (it put a single keyframe at the start and then never, to save space and appear better than realvideo, but both were h263 based afaik) [21:33:41 CEST] <JEEB> after it was mentioned that the episodes would be a few % smaller than with Real Video? [21:34:17 CEST] <atomnuker> yeah, we didn't have anything in the fate samples repo but there's code in lavf [21:34:57 CEST] <durandal_1707> atomnuker: huh? thare are vivo samples... [21:36:02 CEST] <atomnuker> find . -iname "*vivo*", nothing, maybe they used a standard-ish container [21:36:18 CEST] <durandal_1707> extension is viv [21:37:03 CEST] <atomnuker> there are some in samples.ffmpeg.org though [21:37:03 CEST] <durandal_1707> in old days, internet was full of that... [21:38:04 CEST] <atomnuker> nope, seems like we can't decode either video or audio, oh well [21:39:03 CEST] <durandal_1707> you picked 2 version [21:39:33 CEST] <durandal_1707> old version have supported video and audio [21:56:49 CEST] <kierank> C question: [21:56:52 CEST] <kierank> Can I address this int16_t (*blocks)[12][64]; [21:56:58 CEST] <kierank> like this block[128] [21:57:16 CEST] <kierank> if I cast it, that's valid C, right? [21:58:19 CEST] <kierank> actually I need it like block[3][128], is that allowed? [22:00:06 CEST] <durandal_1707> in C its possible , but is not nice to casual reader i guess [22:00:38 CEST] <kierank> durandal_1707: dpcm is in terms of macroblock [22:01:03 CEST] <kierank> actually I need [3][256] [22:01:25 CEST] <kierank> so it not big enough [22:01:30 CEST] <kierank> I will allocate my own buffer [22:02:29 CEST] <kierank> I will do that and let the usual complainers fix it [22:03:11 CEST] <durandal_1707> nobody will complain if code is nice [22:03:28 CEST] <kierank> it might affect benchmarks of mpegvideo.c cache [22:03:30 CEST] <kierank> and stuff [22:03:36 CEST] <atomnuker> just extend the buffer such that it sums up to what you need [22:03:48 CEST] <atomnuker> you can cast it as a pointer and address it linearly [22:04:23 CEST] <durandal_1707> yes, C is forgiving [22:04:32 CEST] <kierank> how do I cast int32_t (*block32)[12][64]; to be int16_t *dpcm_block[3][256]? [22:05:54 CEST] <atomnuker> right, I don't think that's possible, maybe using a union? [22:07:00 CEST] <atomnuker> if you add another field to the struct I wouldn't mind [22:07:38 CEST] <durandal_1707> i hate micro optimizations [22:09:50 CEST] <durandal_1707> does that block have alignment need? [22:10:13 CEST] <atomnuker> kierank: checked, you can just replace block32 with union { int32_t block32[12][64]; int16_t *dpcm_block[3][256]; }; [22:10:40 CEST] <atomnuker> code can still access ctx->block32 as normal and you can access ctx->dpcm_block as you need to [22:11:08 CEST] <durandal_1707> isnt there policy against union? [22:11:13 CEST] <atomnuker> gcc doesn't complain with --std=c89 so I guess anonymous unions are allowed [22:12:08 CEST] <durandal_1707> in c pointers are just integers... [22:13:30 CEST] <rcombs> hmmmm [22:13:54 CEST] <atomnuker> durandal_1707: yeah, you can add stuff to them, they're totally mutable, its awesome! [22:13:55 CEST] <rcombs> if you cast first I _think_ that's fine but lemme double-check [22:15:07 CEST] <durandal_1707> C++ have several cast versions, i dunno what they mean [22:17:46 CEST] <atomnuker> I don't see any anonymous unions in our codebase, but if that's the case just name it block and the variables inside as as_32 and as_dpcm or something [22:18:57 CEST] <atomnuker> yeah, seems like anoymous unions are a c11 thing [22:18:57 CEST] <durandal_1707> yes, iirc anonymous unions are forbiden [22:20:04 CEST] <rcombs> kierank: block[3][128] would be UB [22:20:22 CEST] <rcombs> because you're past the end of a sub-array [22:21:17 CEST] <rcombs> dunno if any compiler would actually punish you for that in practice (might warn? dunno if it'd affect codegen), but it's not defined [22:22:26 CEST] <kierank> I will implement it directly then and let the person who complains fix it [22:54:12 CEST] <kierank> durandal_1707: ping [22:54:46 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/S1Zg4dZV/image.png [22:54:53 CEST] <kierank> is there a function to do this already? [22:55:58 CEST] <kierank> ah unary [22:56:07 CEST] <durandal_1707> is that get unary with twist? [22:57:32 CEST] <durandal_1707> give me something harder as tables that needs conversion to our syntax [23:28:05 CEST] <jamrial> nevcairiel: neat, new msvc version fixed the fate failures [23:31:25 CEST] <nevcairiel> jamrial: yeah i know, they notified me that my ticket was resolved [00:00:00 CEST] --- Sun Aug 19 2018

1 0

ffmpeg.log.20180818
by burek 19 Aug '18

19 Aug '18

[00:07:51 CEST] <pi--> How can I extracted the audio channel from video without re-encoding? [00:15:34 CEST] <Cracki> "copy" codec [00:26:17 CEST] <teratorn> when you seek an input with -ss, do you get PTSs starting at 0 in the filter graph or are the packet timestamps untouched? [00:31:00 CEST] <lmat> I'm running ffplay on a file, and I get https://ptpb.pw/ttxl [00:31:25 CEST] <lmat> I'm running pulse (I'm able to use pavucontrol to change the volume of, for instance, chromium while it's playing something.) [00:35:24 CEST] <lmat> DOH! running as the wrong user. [00:35:28 CEST] <lmat> Thanks guys, you're the best!! [00:36:28 CEST] <Cracki> rubberduckers are the best [00:37:18 CEST] <lmat> Okay, new question... [00:37:21 CEST] <lmat> "Channel layout '5.1' with 6 channels does not match specified number of channels" [00:37:33 CEST] <lmat> I have a 8-channel audio file (.wav; it's for identifying channels) [00:37:40 CEST] <lmat> When I play it, well, let's take a look at the output. [00:38:30 CEST] <lmat> https://paste.ubuntu.com/p/S3crZq7WDv/ [00:38:31 CEST] <lmat> There we go. [00:38:53 CEST] <Cracki> so sdl can't deal with 8 channels [00:39:36 CEST] <lmat> What's SDL? [00:39:40 CEST] <lmat> I should be using pulse? [00:40:59 CEST] <teratorn> for playback? no [00:41:08 CEST] <teratorn> portaudio is what you use for playback and recording [00:41:14 CEST] <lmat> https://i.imgur.com/TxD4V2C.png [00:41:30 CEST] <lmat> teratorn: What's portaudio? I thought I use ALSA drivers? [00:41:56 CEST] <lmat> That is a screenshot of pavucontrol. It suggests 8 channels? [00:42:01 CEST] <teratorn> lmat: I dunno what you are doing. it's an audio library [00:42:18 CEST] <lmat> teratorn: I'm trying to play an 8-channel audio file on 8 different channels... [00:42:44 CEST] <teratorn> in code? on the command line? in a browser? what? [00:42:52 CEST] <lmat> good question! I'm using ffplay. [00:43:04 CEST] <lmat> Earlier, I said, I'm running ffplay on a file, and I get https://ptpb.pw/ttxl [00:43:14 CEST] <teratorn> ffplay is a toy for testing purposes [00:44:00 CEST] <lmat> teratorn: okay, I'll use something else [00:44:01 CEST] <teratorn> lmat: try vlc or mpv [00:44:06 CEST] <lmat> (while noting that this worked a year or two ago ^_^) [00:44:57 CEST] <debianuser> lmat: It probably still works, and those messages could be just warnings. [00:45:19 CEST] <lmat> yeah, VLC is doing okay. [00:45:35 CEST] <lmat> debianuser: It doesn't work because in pavucontrol, it shows only 6 channels. [00:45:53 CEST] <lmat> Okay, I have that audio track looping, now I can get my wiring in place. [00:45:56 CEST] <lmat> Thanks! [00:46:13 CEST] <debianuser> lmat: But if not - it was probably pulseaudio's module injected into alsa's playback chain that is breaking SDL_OpenAudio. You can test that by uninstalling pulseaudio and check with plain alsa (you can install pulse back after the test, of course). [00:47:01 CEST] <debianuser> lmat: On the other hand, if vlc works fine for you - just use it and be happy. :) [00:47:42 CEST] Action: lmat is being happy. [11:14:36 CEST] <realies> can you overlay an audio vumeter over the video stream with ffplay? [23:13:55 CEST] <anden> so i have a video i need to transcode into two new files: one that is rotated 90 degrees and one that is not rotated. the problem is, for some reason, the quality is completed destroyed on the rotated version. i use the -vf "transpose=1" argument. any ideas? [23:16:14 CEST] <anden> here are the full commands i ran: https://pastebin.com/raw/A7B8LBdm [23:17:19 CEST] <TheAMM> Someone will correct me, but if you're not aiming for a specific filesize, twopass is not worth it [23:17:30 CEST] <furq> two-pass is worth it for vpx because its ratecontrol is terrible [23:17:37 CEST] <furq> good prediction though [23:17:52 CEST] <anden> TheAMM: i am actually. and after doing several experiments, these were the optimal settings i came up with [23:17:53 CEST] <TheAMM> Literally every time I offer my help someone will tell me wrong [23:18:01 CEST] <furq> anden: you need to transpose in both passes [23:18:05 CEST] <furq> otherwise the first pass log is useless [23:18:20 CEST] <anden> furq: i did that too, first, but it didn't change anything for the quality [23:18:34 CEST] <TheAMM> furq: does this apply to CRF mode as well? [23:18:39 CEST] <anden> does it matter where on the command line the -vf argument is specified? [23:18:42 CEST] <furq> TheAMM: in vpx, yes [23:18:43 CEST] <furq> anden: no [23:21:58 CEST] <anden> so anything else i can do to get the same video quality on both files? [23:23:07 CEST] <Cracki> encode 10 seconds and check [23:23:17 CEST] <Cracki> you had a bug, that's why. [23:26:26 CEST] <anden> so if you guys don't have any other suggestions, i'll just export all the frames (it's not a very long video anyway) use imagemagick to batch rotate them and encode the image sequence back into the new vide.. [23:27:20 CEST] <furq> that's not really going to make any difference [23:28:30 CEST] <anden> so you're saying it's a problem with the algorithm? that it's not able to encode the video nearly as good when the image is rotated? [23:28:47 CEST] <furq> i'm saying you have some other problem [23:28:54 CEST] <furq> or there's some colossal bug with vpx, which seems unlikely [23:29:19 CEST] <anden> anyway, being out of options for the moment, i'll proceed with imagemagick and we'll see what happens [23:29:22 CEST] <furq> but transpose literally just rotates the decoded frames, it wouldn't do anything that exporting and rotating with another tool wouldn't do [23:29:29 CEST] <anden> yeah, that's what i was hoping [23:29:30 CEST] <TheAMM> on ffmpeg libvpx 2pass works kind of for me [23:29:40 CEST] <furq> anden: are you running the commands in the order in that paste [23:29:50 CEST] <TheAMM> On mpv the logfiles are broken for some reason I haven't figured out yet [23:29:52 CEST] <anden> yes, first pass, then second [23:29:56 CEST] <furq> you're not running both first passes and then both second passes or anything like that [23:30:24 CEST] <Cracki> anden, TRY vf rotate in the first pass. [23:30:27 CEST] <Cracki> TRY it. [23:30:36 CEST] <Cracki> and REPORT the results [23:30:45 CEST] <furq> he said he already tried transposing in the first pass [23:30:49 CEST] <anden> actually, the non-rotated version was done several days ago so yeah, i shouldn't be overwriting the logs [23:30:50 CEST] <Cracki> hm [23:30:57 CEST] <anden> i transposed in both passes, first [23:31:04 CEST] <anden> then only in second. i never tried transposing in only the first pass [23:31:34 CEST] <furq> anden: if you really want to pre-rotate it then just ffmpeg -i input.mkv -vf transpose=1 -c:v rawvideo -c:a copy tmp.mkv [23:31:42 CEST] <furq> then encode that [23:32:08 CEST] <anden> okay, so that will intermediate encode it as uncompressed video? [23:32:11 CEST] <furq> yeah [23:32:14 CEST] <anden> cool [23:32:21 CEST] <furq> i doubt it'll make any difference but it's important to prevent people from using imagemagick [23:32:27 CEST] <anden> :D [23:32:53 CEST] <furq> use -c:v ffv1 or something if you're short on disk space [23:33:10 CEST] <anden> the output VP9 is less than 5MB so it won't be an issue i think [23:38:47 CEST] <poutine> I'm trying to understand how WebVTT captioning should work with HLS live. I read the HLS specification, have googled extensively, and I see synchronization to PTS is done via the X-TIMESTAMP-MAP in the webvtt segment. What I don't understand is 1) What happens if their starting segment in the live stream does not contain that PTS? 2) Can I make segment relative just by dumping the first PTS value of the segment and aligning the timeline to that? 3) If [23:38:47 CEST] <poutine> doing SSDAI and introducing 3rd party video via HLS discontinuity, what happens if that PTS value happens in there? [23:43:45 CEST] <anden> furq: hate to say it, but even extracting the frames from this raw video, the quality already seems bad even before encoding to VP9 [23:44:51 CEST] <anden> hold on, i might have made a mistake. [23:46:53 CEST] <anden> nope, i still stand by my argument. maybe there's a bug with transpose? [23:48:07 CEST] <Cracki> what's this -speed 4 stuff anyway [23:48:25 CEST] <Cracki> could you show us screenshots of what you call "bad"? [23:52:10 CEST] <anden> sorry guys, the raw video is fine. my bad. [23:52:26 CEST] <anden> i guess just encoding that should be fine now. [23:54:09 CEST] <Cracki> what was it? [00:00:00 CEST] --- Sun Aug 19 2018

1 0

ffmpeg-devel.log.20180817
by burek 18 Aug '18

18 Aug '18

[14:17:33 CEST] <JEEB> was cbs_h264 [14:17:41 CEST] <JEEB> the thing that printed out the structure of the H.264 stream? [14:19:19 CEST] <JEEB> ah, trace_headers bsf [15:05:47 CEST] <JEEB> http://up-cat.net/p/7a11a943 [15:06:05 CEST] <JEEB> 12 packets seem to fail in the sample [15:55:55 CEST] <January> jamrial: hits a sigabrt with a 50 frame backtrace in av_malloc if I pass it buf_ref. Guess I'll start digging [15:56:31 CEST] <jamrial> you mean to av_frame_new_side_data_from_buf()? [15:56:49 CEST] <January> jamrial: yes [16:02:44 CEST] <jamrial> that's odd [16:04:53 CEST] <jamrial> it happens when you do https://pastebin.com/xqGA5FsF ? [16:08:43 CEST] <January> jamrial: I wasn't making a53->buf_ref NULL, but making it null seems to fix the issue [16:09:20 CEST] <January> I assume it was trying to realloc the memory in sei [16:11:22 CEST] <jamrial> yeah, as i said, kinda weird semantics on that function. taking ownership of a reference instead of creating a new one for itself was probably a bad idea in hindsight [16:13:59 CEST] <January> jamrial: hopefully i didnt miss anything this time [16:24:32 CEST] <jamrial> January: looks good now [18:18:36 CEST] <cone-724> ffmpeg 03Kieran Kunhya 07master:c85852d3de63: h264: Support multi-field closed captions by using AVBufferRef and not resetting per field [18:22:07 CEST] <jamrial> January: can you add a test for this? [18:25:56 CEST] <January> jamrial: I don't have any samples I can share, do you know of one? [18:26:25 CEST] <JEEB> it's PAFF with A53 per field, right? [18:26:35 CEST] <JEEB> you should be able to stick those SEIs into some PAFF sample [18:27:24 CEST] <JEEB> or not A53, EIA 708 [18:28:05 CEST] <JEEB> meanwhile I should probably poke at the H.264 sample that borks the decoder completely for the rest of the playback session [18:28:19 CEST] <JEEB> it seems like it keeps dropping references or something [18:31:03 CEST] <jamrial> January: no, but maybe you can create one using tmm1's patch for h264_metadata_bsf? [18:31:22 CEST] <jamrial> i don't recall if that was what his patch was meant to do [20:12:40 CEST] <cone-724> ffmpeg 03James Almer 07master:96a7099f3ed5: avcodec/av1_parse: take trailing bits into account when initializing the GetBitContext [20:12:41 CEST] <cone-724> ffmpeg 03James Almer 07master:8d5604a69aaa: avformat/av1: update ff_isom_write_av1c() to the latest revision of the spec [20:19:36 CEST] <cone-724> ffmpeg 03James Almer 07master:728760de350c: Revert "avcodec/libaomdec: auto insert dump_extra bitstream filter" [20:22:55 CEST] <cone-724> ffmpeg 03James Almer 07master:7b5f93d4e126: avformat: bump micro version after previous changes [20:29:24 CEST] <cone-724> ffmpeg 03James Almer 07master:f00964e2f7ea: avformat/av1: filter out tile list OBUs from samples [21:14:03 CEST] <January> jamrial: was i meant to bump lavc [21:15:13 CEST] <jamrial> no, i don't think so [21:15:30 CEST] <jamrial> we don't bump for bugfixes, in general [21:17:07 CEST] <January> jamrial: I guess theres a whole debate whether it was a bugfix or a feature, should be fine if you think so though [21:19:31 CEST] <jamrial> January: feel free to bump lavc micro if you want, in that case. i guess for something like this, a library user may want to make sure the version it's using has your change [21:20:34 CEST] <January> jamrial: Ill bump when i add a test, havent had a chance to look at tmm1s patch yet [21:24:44 CEST] <jamrial> January: actually, i think the patch was by jkqxz, and tmm1 wanted to use it for mediacodec [21:24:52 CEST] <JEEB> 34 [21:25:04 CEST] <jamrial> and it may have been to extract a53, but not include [21:25:42 CEST] <jamrial> they know better about this [21:53:42 CEST] <cone-724> ffmpeg 03Michael Niedermayer 07master:1e71cb2c8edc: avformat/mlvdec: read_string() received unsigned size, make the argument unsigned [21:53:43 CEST] <cone-724> ffmpeg 03Michael Niedermayer 07master:c2eec1762d37: avformat/rmdec: Fix EOF check in the stream loop in ivr_read_header() [00:00:00 CEST] --- Sat Aug 18 2018

1 0

ffmpeg.log.20180817
by burek 18 Aug '18

18 Aug '18

[14:24:18 CEST] <kerio> is there a simple way with the ffmpeg commandline to crop the last column or row to get even sizes? [14:28:25 CEST] <Nacht> if you want to say scale a video with 720p and have an even number of lines, I usually use scale=-2:720 [14:28:36 CEST] <Nacht> So I assume it can be done for crop as well [14:28:38 CEST] <kerio> it's a bunch of gifs that i want to turn to mp4 [14:29:58 CEST] <Nacht> so you could use something like crop=in_w:-2 [14:30:52 CEST] <kerio> i need yuv420 because quicktime is dumb [14:31:28 CEST] <kerio> looks like i can do floor(iw/hsub)*hsub:floor(ih/vsub)*vsub [14:32:26 CEST] <kerio> well ok no i can't because i can't yuv420p before cropping so hsub and vsub are 1 [14:32:43 CEST] <kerio> but i can do floor(iw/2)*2:(ih/2)*2 [14:33:24 CEST] <kerio> this fucking ffmpeg man [14:33:25 CEST] <kerio> it can do everything [18:13:28 CEST] <kexec> hello, please, some recommendation for converting AVC 1080p to MPEG4 720x404? currently i have "ffmpeg -i in.mkv -c:v mpeg4 -vtag xvid -vf scale=720:-1 -qscale:v 3 out.avi" [18:13:42 CEST] <kexec> if there is something i could make better [18:13:51 CEST] <Cracki> no [18:15:13 CEST] <DHE> just maybe you might want to look at actually using the xvid (3rd party) encoder. but mpeg4 should be compatible' [18:15:43 CEST] <DHE> still, mpeg4 is old by today's standards [18:16:37 CEST] <kexec> DHE: yeah, i know but this is for an older TV which cant play AVC. [18:17:03 CEST] <kexec> and can i use the "qscale:v 3" also with xvid? [18:17:28 CEST] <Cracki> consult the docs, then try it. if it doesn't work, ask again. [18:18:09 CEST] <DHE> http://ffmpeg.org/ffmpeg-codecs.html#libxvid <--- docs [18:35:22 CEST] <white_gecko> hello, I'm trying to convet a opus file to apple lossless (alec) with "ffmpeg -i file.opus -c:a alex file.m4a" but I get the error "Unknown encoder 'alec'" [18:35:29 CEST] <white_gecko> even though ffmpeg -codecs lists: "DEAI.S alac ALAC (Apple Lossless Audio Codec)" [18:35:39 CEST] <JEEB> alec != alac [18:35:41 CEST] <kepstin> white_gecko: you misspelled it [18:35:46 CEST] <JEEB> it's not baldwin [18:36:12 CEST] <kepstin> also, converting lossy to lossless is in general silly to do, but I guess if you want something to play on an apple device without losing more quality... [18:41:38 CEST] <Cracki> and the command line contains yet another spelling, "alex" [18:42:03 CEST] <Cracki> feature request: spelling correction for command line arguments [18:53:46 CEST] <white_gecko> ah thenk you [18:54:08 CEST] <white_gecko> thank you [18:54:12 CEST] <white_gecko> sorry for that again [18:54:31 CEST] <white_gecko> abviously I have some weakness here [18:54:54 CEST] <white_gecko> so would it be a good idea to convert opus to aac then? [18:56:11 CEST] <Cracki> no [18:56:30 CEST] <Cracki> why would you? [18:57:22 CEST] <white_gecko> because my A/V receiver does not support opus [18:57:24 CEST] <white_gecko> https://www.onkyo.com/manual/txnr636/adv/en/074.html [18:57:38 CEST] <Cracki> if it doesn't support opus, then of course you have to convert [18:57:45 CEST] <Cracki> to something it DOES support [18:58:07 CEST] <Cracki> in that regard, aac is one of the better choices [18:58:32 CEST] <Cracki> vorbis is outdated. [18:58:40 CEST] <Cracki> flac is a good choice because it's lossless. [19:00:15 CEST] <white_gecko> ok so i go with aac [19:00:19 CEST] <white_gecko> thanks again [19:26:48 CEST] <kexec> please, any help with this? "[libxvid @ 00000178f7d8f940] Invalid pixel aspect ratio 40781/28687, limit is 255/255 reducing" [19:27:21 CEST] <kexec> it repeats to infinity. command line: "ffmpeg -i "in.ts" -c:v libxvid -qscale:v 7 -c:a copy out.avi [19:38:41 CEST] <kepstin> kexec: well, that should be an ignorable warning i think? But you can make it go away by using a setsar filter to fix the value [19:38:54 CEST] <kepstin> what kind of input do you have with such a weird pixel aspect ratio? [19:39:06 CEST] <kexec> kepstin: yeah, but it just repeats that warning and dont do anything [19:39:37 CEST] <kexec> input: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(progressive), 544x436 [SAR 40781:28687 DAR 221394:124819], 25 fps, 25 tbr, 90k tbn, 50 tbc [19:40:19 CEST] <kepstin> wow, that's a really strange size. Is this a cropped part of some other video? [19:42:55 CEST] <kepstin> anyways, assuming the source (before cropping) was widescreen standard definition pal, you want "-vf setsar=sar=64/45" [19:43:37 CEST] <kexec> i am not sure, its a downloaded .ts. however, now i noticed that its being converted in fact, after pressing "s" its displays also the status line [19:48:18 CEST] <kepstin> (or maybe it should be 16:11 instead, you'd have to check by looking at the video) [19:50:02 CEST] <Cracki> people resample video like it's no big deal... [19:50:26 CEST] <Cracki> "cropping" black borders off and rescaling to original size... [20:02:42 CEST] <daddesio> Does ffmpeg currently support seeking with libaom? (e.g. the -ss flag.) I'm unable to use the , key in mpv because lavf is reporting "Seek failed (Operation not permitted)", and indeed, the -ss option doesn't work ("stockholm.ivf: could not seek to position 1.000"). [20:03:11 CEST] <daddesio> Here's how I compiled aom/ffmpeg/mpv: https://pastebin.mozilla.org/9091673 [20:03:38 CEST] <daddesio> mpv log when I use the , key: https://pastebin.mozilla.org/9091677 [20:04:14 CEST] <daddesio> And ffmpeg when I use the -ss flag: https://pastebin.mozilla.org/9091679 [20:04:39 CEST] <daddesio> ffmpeg can decode the file fine as long as I don't seek. [20:22:21 CEST] <kepstin> daddesio: you'd want to put the video into a container with a seek index [20:22:33 CEST] <kepstin> although I don't know what's supported right now for that [21:44:11 CEST] <daddesio> I wonder if ffmpeg currently supports AV1 in another container (e.g. matroska) [21:48:34 CEST] <kepstin> it looks like there's a defined way to store it in webm/matroska, but I haven't checked whether ffmpeg can do that. you could try building it from git if it's not in the 4.0 release. [21:55:04 CEST] <kepstin> it looks like some recent version of mkvmerge has experimental support for av1 [22:16:23 CEST] <JEEB> kepstin: it's still not fully defined IIRC [22:16:43 CEST] <JEEB> FFmpeg has now kind of support for the drafts for both mp4 and matroska, of which actually mp4 seems to be further [22:17:19 CEST] <kepstin> daddesio: I have a better idea: seek to the frame you want before encoding in av1. That'll be way faster because you don't have to encode the video that comes before it ;) [22:18:02 CEST] <kepstin> (i suppose it won't help if you're trying to debug an issue in the encoding of a particular frame in an existing video tho) [22:18:26 CEST] <JEEB> so yea, I'd recommend with master FFmpeg to output into mp4 I guess :P [22:18:29 CEST] <daddesio> yeah, for now I'll just decode to lossless (e.g. y4m or FFV1) ahead of time [22:18:55 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=8d5604a69aaa5e9ce6e930fcae… [22:19:04 CEST] <kepstin> oh, is mp4 supported in ffmpeg now? that would work fine for this. [22:20:15 CEST] <JEEB> just understanding that they're still more or less herping a derp around the exact structure of the extradata [22:22:14 CEST] <kepstin> my experience with av1 is that I tried encoding a frame with it once, but didn't feel like waiting for it to finish. [22:22:25 CEST] <kepstin> but that was a while ago [22:44:48 CEST] <TD-Linux> daddesio, it currently supports av1 in mp4 [22:44:58 CEST] <TD-Linux> however it needs patches from the ml [22:45:25 CEST] <JEEB> what james just pushed wasn't enough? [22:45:33 CEST] <JEEB> (the one I linked) [22:45:43 CEST] <TD-Linux> oh [22:45:50 CEST] <TD-Linux> yeah that's good [22:46:00 CEST] <TD-Linux> remuxing from ivf won't work yet though [22:46:16 CEST] <TD-Linux> it needs a) my patch on the ml and b) a parser [23:58:20 CEST] <Cracki> you keep talking about IVF... https://en.wikipedia.org/wiki/In_vitro_fertilisation [00:00:00 CEST] --- Sat Aug 18 2018

1 0

ffmpeg-devel.log.20180815
by burek 16 Aug '18

16 Aug '18

[00:00:13 CEST] <atomnuker> since reviewing 1 patch large is much easier than 1000 small ones [00:00:26 CEST] <atomnuker> and much less stressful since there's no shit code in master [00:00:41 CEST] <atomnuker> don't try to shift the blame on me [00:00:52 CEST] <atomnuker> you're responsible for mentoring and reviewing the patches [00:01:03 CEST] <atomnuker> and it was your fault for pushing without any agreement from anyone [00:01:27 CEST] <atomnuker> and then it was also yours and a few others fault for objecting to revert and instead keeping this shit in master [00:01:55 CEST] <atomnuker> how can I not be angry? there's shit code in git master and its all your fault, and partially everyone in the project's [00:02:01 CEST] <atomnuker> you haven't even apologized [00:02:11 CEST] <atomnuker> nor admitted what you did was wrong [00:05:47 CEST] <atomnuker> instead there's been a few patches with mismatching description for what they're supposed to do [00:10:24 CEST] <atomnuker> which give little indication the code is heading in a right direction but that's it [00:14:30 CEST] <jamrial> [19:01:03] <@atomnuker> and it was your fault for pushing without any agreement from anyone [00:14:50 CEST] <jamrial> he's the mentor of the project. of course he can push if he thinks the code the student wrote is good [00:15:08 CEST] <jamrial> have you seen a third party ever having to chime in for other gsoc projects? [00:24:17 CEST] <atomnuker> jamrial: 10k line patches are unreasonably large to merge without some indication from someone else they seem reasonable [01:35:02 CEST] <cone-246> ffmpeg 03Jacob Trimble 07master:67599812a36a: avutil/encryption_info: Fix size calculation. [07:25:40 CEST] <loosechainsaw> when using cuda for hardware acceleration is the output pixel format always NV12 [07:26:48 CEST] <loosechainsaw> I am successfully decoding h264 and copying buffers with cuda but mjpeg is not rendering correctly [07:27:04 CEST] <loosechainsaw> wondering if the output format is not necessarily nv12

1 0

ffmpeg.log.20180815
by burek 16 Aug '18

16 Aug '18

[00:48:14 CEST] <TheAverageKappa> HEy [00:49:09 CEST] <TheAverageKappa> Hey guys, I'm trying to use m:key[:value] to match specific stream types [00:49:26 CEST] <TheAverageKappa> Specifically, I'm trying to remove subtitles with the type hdmv_pgs_subtitle [00:49:42 CEST] <TheAverageKappa> What's the key for 'stream type'? [01:03:21 CEST] <c_14> I think you can only use things ffprobe lists with TAG:, codec_name isn't one of those [01:03:45 CEST] <c_14> what you can do though is output ffprobe to csv or json, parse that in a script and then call ffmpeg with the information [06:21:55 CEST] <ZeroWalker> probably asked this before, been searching but can't find it so, yeah. does ffmpeg have a way to cut out a part of a video, and re-encode if it needs to cause of keyframe misses? [07:29:03 CEST] <loosechainsaw> when using cuda for hardware acceleration is the output pixel format always NV12? [07:32:10 CEST] <loosechainsaw> using ffmpeg in code for mjpeg and not getting any joy when copying out of avframe data[0] and data[1] to another cuda buffer [07:32:35 CEST] <loosechainsaw> thought the output would be nv12 so my existing cuda kernel function should continue to work

1 0