July 2018 - Ffmpeg-devel-irc - lists.ffmpeg.org

ffmpeg-devel.log.20180730
by burek 31 Jul '18

31 Jul '18

[02:33:03 CEST] <cone-680> ffmpeg 03James Almer 07master:c38b9c2bf742: configure: add missing aandcttables dependency to mpegvideoenc [02:33:03 CEST] <cone-680> ffmpeg 03James Almer 07master:269daf5985db: configure: add missing aandcttables dependency to asv1 and asv2 encoders [06:32:54 CEST] <cone-334> ffmpeg 03Michael Niedermayer 07master:67fb9c75efec: doc/formats: Add documentation for skip_estimate_duration_from_pts [07:40:19 CEST] <cone-334> ffmpeg 03Antonio Morell 07master:6f3e2913f52b: libavformat/dashenc: Fix relative URI of HLS master playlist [10:51:31 CEST] <cone-334> ffmpeg 03Tobias Rapp 07master:b82632b59f11: tests/audiogen: raise channel count limit to 12 [10:51:32 CEST] <cone-334> ffmpeg 03Tobias Rapp 07master:ec517ad9f9d4: fate: add tests for audio channel up-/downmixing with pan filter [16:02:12 CEST] <soteri> Any of the maintainers of the project available to do some FFMPEG consulting for some issues my company is facing with our FFMPEG-based video-processing pipeline? If you are please msg me personally so that we can have a quick chat about the issues we are facing and to see if you can assist in resolving these issues for us [22:40:30 CEST] <gnafu> Does the libaom-av1 encoder not require -b:v 0 for constant quality mode like libvpx-vp9? [22:41:30 CEST] <gnafu> I just noticed -b:v 0 isn't included in the AV1 wiki article. [23:03:16 CEST] <cone-250> ffmpeg 03James Almer 07master:a9a433564d73: avcodec/h264_mp4toannexb_bsf: use enum constants for the NAL unit type values [00:00:00 CEST] --- Tue Jul 31 2018

1 0

ffmpeg.log.20180730
by burek 31 Jul '18

31 Jul '18

[04:17:00 CEST] <duriangray> hi guys - quick question. I am trying to using ffmpeg to copy a stream. how do i access it? [04:17:24 CEST] <duriangray> ffmpeg -i "http://myurl.com" -c copy -f mpegts "udp://localhost:1935" [04:35:57 CEST] <duriangray> i can not access via VLC player for some reason [05:23:41 CEST] <duriangray> av_interleaved_write_frame(): Broken pipeB time=00:00:10.00 bitrate=4641.1kbits/s speed=2.12x [05:23:41 CEST] <duriangray> Error writing trailer of http://127.0.0.1:8080/publish/stream: Broken pipe [12:33:30 CEST] <th3_v0ice> What could cause this discrepancy between desired output being this: [12:33:39 CEST] <th3_v0ice> Stream #0:0: Video: h264, 1 reference frame ([7][0][0][0] / 0x0007), yuv420p, 1280x720 (0x0) [SAR 1:1 DAR 16:9], q=2-31, 29.97 fps, 29.97 tbr, 1k tbn [12:33:49 CEST] <th3_v0ice> to actually being this: Stream #0:1[0x101]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 59.94 fps, 14.99 tbr, 90k tbn, 119.88 tbc. I am using the API. [13:08:14 CEST] <Hola> Hi every one, I am facing an issue with fifo muxer and RTMP. Straight an example from the ffmpeg official wiki, which i am trying to use but I am getting some weird results. [13:08:32 CEST] <Hola> The command from ffmpeg wiki for fifo muxer: ffmpeg -re -i /home/user/Videos/movie.mp4 -acodec aac -vcodec libx264 -f fifo -fifo_format flv -map 0:v -map 0:a -drop_pkts_on_overflow 1 -attempt_recovery 1 -recovery_wait_time 1 -max_recovery_attempts 20 -threads 1 rtmp://x.rtmp.youtube.com/live2/some-stream-key [13:09:19 CEST] <Hola> I have done replacements and added one extra parameter "-max_recovery_attempts 20" which even if removed shows weird result. [13:10:41 CEST] <Hola> First issue as I can see from output is the Bitrate is N/A and size as N/A. here is one line output as all the output lines have same BitRate and Size. frame= 81 fps= 23 q=28.0 size=N/A time=00:00:03.49 bitrate=N/A speed=0.99x [13:11:58 CEST] <Hola> In the Youtube streaming dashboard, it complains that " You need to change the video resolution. The current resolution is (65535x65535), which is not supported for this configuration. The expected video resolution is (2560x1440)." [13:12:58 CEST] <Hola> If i put -f flv before rtmp url, then it works fine but then I can't use reconnectivity and connection recovery feature from fifo muxer. Any body here to help? [13:59:45 CEST] <ChocolateArmpits> Hola, what version are you running? [14:23:01 CEST] <Hola> ffmpeg version 4.0-static [14:23:07 CEST] <Hola> ChocolateArmpits, here you go [14:23:19 CEST] <Hola> its a static build. [14:31:55 CEST] <ChocolateArmpits> Hola, does it work with all fifo-related parameters, except fifo_format removed? [14:44:32 CEST] <Hola> ChocolateArmpits, i have to check that [14:44:35 CEST] <Hola> let me get back to u [14:47:08 CEST] <Hola> ok if i remove -fifo_format and use -f flv before rtmp and try to mimic the network connection issue, it gives me "av_interleaved_write_frame(): Broken pipe" [14:49:03 CEST] <ChocolateArmpits> what I meant was more like this [14:49:16 CEST] <ChocolateArmpits> ffmpeg -re -i /home/user/Videos/movie.mp4 -acodec aac -vcodec libx264 -f fifo -fifo_format flv -map 0:v -map 0:a rtmp://x.rtmp.youtube.com/live2/some-stream-key [14:53:24 CEST] <Hola> ChocolateArmpits, that didn't help. Same issue appearing. And even it fails with Error writing trailer of rtmp://x.rtmp.youtube.com/live2/xxxx: End of file [14:54:15 CEST] <ChocolateArmpits> Hola, can you paste the output log ? obviously with the key removed [14:54:15 CEST] <Hola> if i put those options then it tries to auto recover which is what I want. But the Bit Rate and Size is NA that causes the remote Youtube RTMP server to show weird resolution. (Thats my assumption :)) [14:56:42 CEST] <Hola> I have removed my stream key from log. but u can access log here . https://pastebin.com/j35sicX0 [14:57:16 CEST] <Hola> I disconnected my network for 10+ seconds and then re-enabled it. [14:57:43 CEST] <Hola> If i put those reconnection parameters, then it does not break like the one in logs. It tries to reconnect successfully when network comes online. [14:59:14 CEST] <ChocolateArmpits> but regardless of that, did youtube receive a compatible stream ? [15:00:57 CEST] <soteri> Hi guys [15:01:50 CEST] <soteri> Any of the maintainers of the project available to do some FFMPEG consulting for some issues my company is facing with our FFMPEG-based video-processing pipeline? [15:02:39 CEST] <soteri> if you are please msg me personally so that we can have a quick chat about the issues we are facing and to see if you can assist in resolving these issues for us [15:02:40 CEST] <Hola> ChocolateArmpits, here is the screen shot https://ibb.co/f5d4G8 [15:02:44 CEST] <Hola> same issue [15:04:21 CEST] <ChocolateArmpits> Hola, can you try setting an appropriate resolution on the command line? [15:04:46 CEST] <Hola> ok is it with -s 400x400? [15:05:32 CEST] <ChocolateArmpits> yeah, just change the numbers to something that seems youtube-ish [15:06:26 CEST] <Hola> ok [15:07:14 CEST] <Hola> it does not have any effect. [15:07:28 CEST] <Hola> same issue appearing. [15:11:22 CEST] <Hola> It does not even use provided bitrate etc. [15:13:53 CEST] <ChocolateArmpits> Hola, I think you should then try rather than streaming rtmp to youtube, try to do it locally [15:15:32 CEST] <ChocolateArmpits> even if you raise the issue on the bug tracker, to have it solved faster it will be best to do all sorts of tests run under with debug loglevel [15:15:56 CEST] <while> anyone know about concatenating png's as frames onto the end of an ogg theora/vorbis file? [15:16:56 CEST] <ChocolateArmpits> while are the frames named in a predictable manner? [15:17:07 CEST] <while> yes [15:18:31 CEST] <ChocolateArmpits> then have two inputs, one of the theora file, the other as an image sequence using -f image2 and appropriate input options for it. Then use the concat multimedia filter to append the second video source to the first. You'll have to match the resolution and the pixel format of both inputs to match [15:18:48 CEST] <while> thank you [15:20:21 CEST] <while> and does the same principal hold for audio pieces (such as in .wav or .mp3)? [15:20:57 CEST] <Hola> ChocolateArmpits, thanks for information. but do you feel its a bug? [15:21:26 CEST] <ChocolateArmpits> Hola, I've had issues with fifo muxer and rtsp but on windows, that was solved after I filed a bug report [15:22:18 CEST] <ChocolateArmpits> while, it's the same filter for audio as well. Look in the documentation https://ffmpeg.org/ffmpeg-filters.html#concat [15:23:28 CEST] <ChocolateArmpits> Hola, here's the fixed ticket https://trac.ffmpeg.org/ticket/6308 [15:23:34 CEST] <ChocolateArmpits> for a reference [15:24:06 CEST] <ChocolateArmpits> Hola, read this if you want to report bugs [15:24:06 CEST] <ChocolateArmpits> http://ffmpeg.org/bugreports.html [15:25:34 CEST] <Hola> all right - Thank you ChocolateArmpits for all the help :)) [15:25:38 CEST] <ChocolateArmpits> np [15:31:19 CEST] <Hola> ChocolateArmpits, with more debug logs i found an issue : cur_dts is invalid (this is harmless if it occurs once at the start per stream) [15:31:32 CEST] <Hola> and its appearing again and again [15:32:24 CEST] <ChocolateArmpits> Hola, dts is display timestamp upon decode, so it shouldn't be related if flv by itself works with youtube [15:32:59 CEST] <ChocolateArmpits> though if you think your input is bad, you can try using testsrc lavfi video input [15:33:07 CEST] <ChocolateArmpits> and sine lavfi filter for audio [15:33:47 CEST] <Hola> ok, i will try that. [15:33:47 CEST] <ChocolateArmpits> so [15:33:48 CEST] <ChocolateArmpits> ffmpeg -f lavfi -re -i testsrc2=s=1280x720 -f lavfi -re -i sine -map 0:v -map 1:a [15:36:05 CEST] <Hola> just tried it, same issue with fifo muxer. [15:36:17 CEST] <Hola> I think i need to try master branch to see if its different [15:36:31 CEST] <Hola> Thanks alot ChocolateArmpits :) [18:04:03 CEST] <th3_v0ice> Could a decoder time_base somehow be screwed up? av_dump_format() shows that decoder time_base is 1001/60000, but when I start to decode its 1001/120000. [18:04:42 CEST] <th3_v0ice> Problem occurs in the output file where the framerate is not 29.97fps but 15fps. If I divide the packet.pts and packet.dts in half, then it works properly. [18:05:10 CEST] <th3_v0ice> Does anyone know what could be the problem? [18:08:12 CEST] <kepstin> th3_v0ice: not sure what you mean - is the value stored in the avstream->time_base changing? [18:10:30 CEST] <th3_v0ice> kepstin: Not in the avstream->time_base. Stream base doesnt change. But the AVCodecContext->time_base when I open the decoder context is at 1001/60000, but when I start to decode it changes to 1001/120000. [18:11:29 CEST] <kepstin> th3_v0ice: you've read the comments on the AVCodecContext stuff? the time_base field there is deprecated, and there's some weird stuff involving the ticks_per_frame field in mpeg2 and h264. [18:13:44 CEST] <kepstin> I think unless you do any conversions yourself, the timestamps on both the avpacket and avframe should be in the avstream timebase [18:15:04 CEST] <kepstin> (the transcoding.c example explicitly converts from stream to codec timebase before decoding) [18:15:09 CEST] <th3_v0ice> kepstin: Thanks for pointing this out! I have overlooked this information. It says that I should use the framerate instead. What would be the correct way to do that actually? [18:15:31 CEST] <kepstin> easiest thing? completely ignore the codec context timebase for decoding and just leave everything in stream timebase [18:15:59 CEST] <th3_v0ice> Haha, any other way? Just in case that this fails. [18:16:25 CEST] <kepstin> other way is to do what the transcoding.c example does, and convert from stream timebase to codec timebase before sending the packet to the decoder [18:17:17 CEST] <th3_v0ice> I was doing that already actually. [18:18:22 CEST] <kepstin> but (iirc), the decoder should be simply passing through the pts provided on the input packets to the pts on the output frames. [18:21:10 CEST] <th3_v0ice> But isnt the trancoding.c using the field that is deprecated? [18:21:23 CEST] <th3_v0ice> the AVCodecContext->time_base? [18:22:03 CEST] <kepstin> yes, it's an old example [18:23:53 CEST] <th3_v0ice> Removing the av_packet_rescale_ts(packet, stream->time_base, codec->time_base) makes 50fps in the output file :) [18:25:14 CEST] <kepstin> well, you have to check that all your other scaling on the encoding side is correct, too - that the encoder timebase is set to match what you're sending to it, and you're rescaling to the container timebase after encoding. (container can reject your requested timebase and tell you to use a different one) [18:27:59 CEST] <th3_v0ice> Hmmm, that is actually the missing link that I was thinking about this whole time. So encoder->time_base and decoder->time_base should be identical? [18:30:24 CEST] <kepstin> th3_v0ice: there's no reason for them to be the same, but if it simplifies your code, why not? [18:30:53 CEST] <kepstin> (an example where they'll be different is if you're using filters, and there's a filter that changes timebase) [18:31:35 CEST] <kepstin> in that case, you'd set the encoder timebase to the filter's output timebase, of course. [18:38:04 CEST] <th3_v0ice> kepstin: Can I then specify the buffersink time_base? [18:38:30 CEST] <th3_v0ice> Or how can I set the filter to change the time_base? [18:39:52 CEST] <kepstin> for buffersink, you'd have to read the timebase out of the ctx->inputs[0]->time_base field [18:40:04 CEST] <kepstin> that'll be the time_base of the frames you're getting from the buffersink api [18:41:36 CEST] <th3_v0ice> Hmm, ok, but is it possible to get the filter to change the input time_base to output time_base? From buffersrc->time_base to buffersink->time_base? [18:44:19 CEST] <kepstin> no, you should do that yourself. It's just a single function call to rescale pts values, way easier than setting up a filter chain... [18:45:14 CEST] <th3_v0ice> Thanks for helping me man! I will rescale the values manually was just wondering if its possible to do with filters. [18:45:26 CEST] <kepstin> what I meant was that some filters, as a side-effect of whatever other operation they do, also change the timebase [18:46:04 CEST] <kepstin> e.g. the fps filter changes the video framerate (drop/duplicate frames), and also sets a new timebase calculated from the requested framerate. [18:47:01 CEST] <th3_v0ice> Oh, ok. Thanks once again! [18:47:09 CEST] <kepstin> so if you use filters, you have to remember that the output of the filters might be a different timebase from the input - which means you have to either set the encoder timebase to the value from the filter output, or rescale them [18:48:34 CEST] <th3_v0ice> Ok [18:49:50 CEST] <th3_v0ice> Thanks! [19:30:36 CEST] <lungaro> i'm curious of taking a live video feed of a IP camera and saving it locally. Is anyone aware of a place to look for video cameras which support this? [19:38:51 CEST] <CoreX> lungaro are you using ffmpeg to do it ? [19:43:52 CEST] <lungaro> That's what I was thinking but am not sure tbh, I am a IP camera newb [19:49:30 CEST] <DHE> there are lots of cameras as well. I've seen some that let you put in FTP credentials and it auto-uploads any time it sees movement... in which case no ffmpeg required. [19:50:22 CEST] <lungaro> interesting, i'll have to do some more research then, I dont know where to find these cameras yet, but I suppose I should settle on WIFI/IP [19:52:31 CEST] <DHE> I've seen cameras that support rtsp as well, and ffmpeg can connect to that just fine. etc. [19:52:41 CEST] <lungaro> nice [00:00:00 CEST] --- Tue Jul 31 2018

1 0

ffmpeg-devel.log.20180729
by burek 30 Jul '18

30 Jul '18

[03:51:09 CEST] <cone-264> ffmpeg 03James Almer 07release/3.1:a9c1ef262636: avcodec/bitstream_filters: check the input argument of av_bsf_get_by_name() for NULL [03:51:09 CEST] <cone-264> ffmpeg 03James Almer 07release/3.2:ecafc4af95b4: avcodec/bitstream_filters: check the input argument of av_bsf_get_by_name() for NULL [03:51:09 CEST] <cone-264> ffmpeg 03James Almer 07release/3.3:660e4c0c961c: avcodec/bitstream_filters: check the input argument of av_bsf_get_by_name() for NULL [03:51:10 CEST] <cone-264> ffmpeg 03James Almer 07release/3.4:bc2301429e9c: avcodec/bitstream_filters: check the input argument of av_bsf_get_by_name() for NULL [03:51:12 CEST] <cone-264> ffmpeg 03James Almer 07release/4.0:9cc5337247b2: avcodec/bitstream_filters: check the input argument of av_bsf_get_by_name() for NULL [10:20:12 CEST] <JEEB> michaelni: https://patchwork.ffmpeg.org/patch/9836/ I don't /think/ there are any other ISMV tests, and I checked that all changed tests' results seem to make sense (the three updated ones were just the version value of that one box, no other values were changed) [10:20:19 CEST] <JEEB> boxdumper <3 [20:06:44 CEST] <philipl> BtbN: For when you get back, I created a PR for the new SDK stuff. [20:07:11 CEST] <BtbN> Can't really accept PRs, as it will get overwritten by the mirror script, but I'll look into it. [20:08:47 CEST] <philipl> Fair. Can I push to videolan for this repo? I've never tried. If you're ok with it, I'll try and push it [20:08:47 CEST] <BtbN> Did the nvenc header really not change at all? [20:08:53 CEST] <philipl> It did not. I did a careful diff. [20:09:12 CEST] <BtbN> Yeah, pushing to videolan will end up on github automatically. [20:09:37 CEST] <philipl> They added a name to that anonymous inner struct in the vp8 params, which was nice, after all the problems I had setting it. Can't use it until we drop old SDK support of course. [20:10:33 CEST] <BtbN> Patch looks fine to me, feel free to push it to the videolan repo [20:10:47 CEST] <philipl> Done. It worked. [21:07:21 CEST] <philipl> n [22:12:58 CEST] <Robert34> Hi, I use avcodec_decode_audio4 on raw aac frames. The resulting AVFrame struct always has nb_samples == 1024. This is wrong, since only the average is 1024 samples/frame, any ideas? [22:16:02 CEST] <rcombs> nope, that's how many samples in a (LC or similar-profile) AAC frame [22:20:36 CEST] <Robert34> Then how is it possible that the 'stts' atom doesn't only contain 1024 samples/frame? [22:20:57 CEST] <kierank> what does it say [22:21:20 CEST] <kierank> 1024 is correct [22:23:51 CEST] <Robert34> 242 f with 1024; 1 f with 384; 2 f with 1024; 1 f wit 1280; 1 f with 1056; 80 f with 1024; ........... and so on, the average is indeed 1024, but some have more or less [22:24:04 CEST] <kierank> buggy mux [22:24:42 CEST] <Robert34> ? [22:26:25 CEST] <Robert34> I am trying to restore the 'stts' table and therefore need those "wrong" values. Otherwise the audio is out of sync with video [22:27:52 CEST] <Robert34> there are even frames which have 351232 samples [22:33:46 CEST] <nevcairiel> aac frames always have 1024 samples, or 960 in those profiles [22:34:01 CEST] <nevcairiel> there is no way around that [22:37:11 CEST] <Robert34> But there must be a way to manually count the samples in one frame, right? [22:39:13 CEST] <Robert34> What would be the purpose of the 'stts' table if all frames really contain 1024 samples? [22:44:19 CEST] <kierank> could have formats (e.g opus) which are variable [22:53:48 CEST] <Robert34> So I gues it's sort of a cheap hack from the encoder to keep the audio and video in sync? [22:54:12 CEST] <Robert34> the codec of my file is AAC LC [22:58:11 CEST] <kierank> looks like a corrupt file [23:01:23 CEST] <Robert34> it's the recording of a .m3u live stream. So if the network does not deliver audio it kind of makes sense to put "fake" samples into the stts. But that also means there is no way to recover them... [00:00:00 CEST] --- Mon Jul 30 2018

1 0

ffmpeg.log.20180729
by burek 30 Jul '18

30 Jul '18

[04:00:06 CEST] <TheTallesT> Any ideas on why ffmpeg would return "Unknown encoder 'libcelt'" when compiled with --enable-libcelt and libcelt is listed in the output of 'ffmpeg -codecs'? [04:02:28 CEST] <furq> libcelt is only for decoding iirc [04:02:49 CEST] <furq> i don't have a build with it but if it doesn't have an E in ffmpeg -codecs then it's decode only [04:03:01 CEST] <DHE> the letter codes in front of the codec indicate its types. 'D' for decode, 'E' for encode, etc [04:04:12 CEST] <furq> also i assume you want celt for compat reasons, because it was obsoleted by opus a while back [04:04:13 CEST] <TheTallesT> my bad.. thank you [11:33:12 CEST] <linuxmaster> /bin/kill -HUP $MAINPID #does it work for avconv to change settings? [11:46:10 CEST] <linuxmaster> how to use avconv as systemd service? [13:41:14 CEST] <DHE> well, avconv is the old ffmpeg fork binary. (or maybe a compatibility name from people who used it). second ffmpeg isn't a background service [14:50:02 CEST] <linuxmaster> DHE: really? -nostdin and we have background service [15:39:21 CEST] <DHE> linuxmaster: well if you're doing that then you still need to give it the rest of the commandline. so really you're defining your own service [15:39:25 CEST] <DHE> also, systemd. eww. :) [15:47:19 CEST] <JEEB> DHE: as an init system it's much better than f.ex. sysv init or upstart [15:48:17 CEST] <JEEB> speaking as someone who has gone through cargo cult sysv files, then upstart config files and finally systemd service files [16:11:23 CEST] <BtbN> Anyone ever had issue with using the segment muxer to create a bunch of .ts files, and then when stitching them back together there is sometimes slight audio glitches on the boundaries of the segments? [16:27:23 CEST] <bodqhrohro1> If in geq red_expr I sum values from several pixels, do they get trunkated by the maximum value or overflown? [16:30:54 CEST] <DHE> JEEB: while I disagree, this is not the place to be talking about it. [16:31:40 CEST] <DHE> I've found ffmpeg isn't that great of a continuously running daemon because a continuous video feed is never reliable enough to make it happy. [16:55:32 CEST] <linuxmaster> NEVER. Never use symbol links in your systemd units! [17:00:46 CEST] <bodqhrohro1> linuxmaster: what happened? [17:12:14 CEST] <bodqhrohro1> And what scale does red_expr have? Is it 0..255, or 0..1? [17:14:01 CEST] <JEEB> DHE: dunno, I've seen ffmpeg.c happily churn for days from a live input which is why a lot of PoCs are too simple to do with it and people think they can get away with ffmpeg.c by itself :D [17:17:09 CEST] <hrvoje> From my experience, ffmpeg works very reliably for days and weeks, even in nvidia (nvenc) configuration [17:30:21 CEST] <rasten33> i got 101 problems but systemd aint one [17:35:07 CEST] <Cracki> didn't you mean 109 [19:03:41 CEST] <alcane> I have a 3.3GB mp4 that won't open in vlc or mpv. Ideas on how I should go about cutting this down? How can I find how long the video is? [19:06:13 CEST] <JEEB> try ffprobe'ing it? the track duration should be a general field in ISOBMFF (aka "mp4") [19:06:30 CEST] <JEEB> or if that doesn't work, `boxdumper --box file.mp4` and pipe into less or something [19:06:44 CEST] <JEEB> which will show you all the boxes in the file [19:06:53 CEST] <JEEB> (boxdumper is part of l-smash) [19:10:55 CEST] <alcane> JEEB: moov atom not found =/ [19:11:31 CEST] <JEEB> sounds like you're missing the initialization data [19:11:46 CEST] <JEEB> if this is a web rip, make sure you get the initialization segment first [19:11:52 CEST] <JEEB> and prepend it to the whole thing [19:15:44 CEST] <alcane> no, it's a video someone recorded on their laptop [19:15:53 CEST] <alcane> mplayer cli revealed it's a rawdv file [19:16:32 CEST] <JEEB> I'd be surprised, since usually libavformat can probe the container [19:16:46 CEST] <JEEB> even if the extension looks like something else [19:17:49 CEST] <alcane> so.... transcode it? I'm not familiar with video, lol [19:17:50 CEST] <JEEB> not suer what exactly "rawdv" means but if it's "dv" then `ffmpeg -f dv -i file` might output something (will probably work with ffprobe as well) [19:20:48 CEST] <alcane> JEEB: https://pastebin.com/mAGVGYv2 [19:22:22 CEST] <JEEB> that's probably not raw DV [19:22:31 CEST] <JEEB> if it can find a major brand etc [19:22:46 CEST] <JEEB> most likely the file is just cut in the middle before writing was finished? [19:23:34 CEST] <alcane> i wouldn't doubt it. I'm pretty sure he just hit record and let it fill ram/cache until his computer crashed, lol [19:23:37 CEST] <JEEB> if l-smash's boxdumper can output sensible stuff then I'd say it's an mp4 file but never finished [19:24:27 CEST] <JEEB> alcane: there's some apps for possibly fixing such things if you have a working example, but in general it's not a good idea to do non-fragmented mp4 if you are going to have a thing crash or just get killed before it writes all the data [19:25:34 CEST] <JEEB> basically something with the exact same parameters/resolution/etc from the same camera/capture software [19:25:49 CEST] <alcane> that's why I don't record things with a computer. They make camera's for such things. ;) I just wanna get this guy his video file watchable in some form. [19:26:00 CEST] <JEEB> even cameras can stop before they finished their mp4 [19:26:09 CEST] <JEEB> we've had plenty of people come here with camera files [19:26:15 CEST] <JEEB> with a similar issue [19:26:34 CEST] <alcane> so this boxdumper is it's own program? [19:26:44 CEST] <DHE> more like using a format or settings that produce a crash-tolerant file [19:26:57 CEST] <alcane> so it's a cli? [19:32:32 CEST] <alcane> oh well, it's the other dude's problem. I tried. Thanks! [19:33:59 CEST] <linuxmaster> bodqhrohro1: they do not work in units [19:34:34 CEST] <linuxmaster> bodqhrohro1: /usr/bin/avconv is a symbol link to /usr/bin/ffmpeg [19:34:34 CEST] <bodqhrohro1> linuxmaster: just like in AppArmor, huh [19:35:15 CEST] <linuxmaster> bodqhrohro1: well... When I use absolute links - it works [19:35:33 CEST] <linuxmaster> feel myself stupid [20:35:02 CEST] <bodqhrohro1> Here's an MWE: [20:35:03 CEST] <bodqhrohro1> [0:v] geq=cr=st(mod(X\,8)+1\, cr(X\,Y))\; ld(mod(X+1\,8)+1): cb=cb(X\,Y):lum=lum(X\,Y) [out] [20:35:03 CEST] <bodqhrohro1> This filter works totally not as I expect it to. Instead of halo, there are strange vertically teared flakes https://pic4a.ru/87/g0i.jpg What order are pixels processed in? [20:36:58 CEST] <bodqhrohro1> Oh, I think I got it. cb/cr resolution is twice less than luminance one [20:43:30 CEST] <ayum> Hi, I have a question about the hwdownload and hwupload filter, if I use the command like this -hwaccel cuvid -c:v mpeg2_cuvid -i URL filter_complex "hwdownload,format=nv12,split=2[out0][out1];[out0]hwupload;[out1]hwupload" -c:v h264_nvenc ..., It's correct or not? seems it will increase huge memory copy overhead [22:12:23 CEST] <Robert34> Hi, I use avcodec_decode_audio4 on raw aac frames. The resulting AVFrame struct always has nb_samples == 1024. This is wrong, since only the average is 1024 samples/frame, any ideas? [22:15:26 CEST] <atomnuker> no, aac always has 1024 samples per frame [22:20:25 CEST] <Robert34> Then how is it possible that the 'stts' atom doesnt only contain 1024 samples/frame? [00:00:00 CEST] --- Mon Jul 30 2018

1 0

ffmpeg-devel.log.20180728
by burek 29 Jul '18

29 Jul '18

[01:10:58 CEST] <cone-557> ffmpeg 03Timo Rothenpieler 07master:ed647ab79f9a: avformat/librtmp: fix returning EOF from Read/Write [01:12:08 CEST] <cone-557> ffmpeg 03Timo Rothenpieler 07release/4.0:d6d7853b4b12: avformat/librtmp: fix returning EOF from Read/Write [14:43:40 CEST] <cone-910> ffmpeg 03Michael Niedermayer 07master:51290406461e: avcodec/diracdec: Prevent integer overflow in intermediate in global_mv() [14:43:40 CEST] <cone-910> ffmpeg 03Michael Niedermayer 07master:69cac9e130dc: avcodec/dirac_dwt_template: Fix several integer overflows in horizontal_compose_daub97i() [14:43:40 CEST] <cone-910> ffmpeg 03Michael Niedermayer 07master:462d1be6dec5: avcodec/diracdec: Change frame_number to 64bit as its a 32bit from the bitstream and we also have a -1 special case [14:43:40 CEST] <cone-910> ffmpeg 03Michael Niedermayer 07master:f457c0ad7f73: avcodec/diracdec: Check slice numbers for overflows in relation to picture dimensions [14:43:40 CEST] <cone-910> ffmpeg 03Michael Niedermayer 07master:bed125b71084: avcodec/diracdec: Check bytes count in else branch in decode_lowdelay() too [16:16:40 CEST] <cone-910> ffmpeg 03James Almer 07master:3258cc6507a2: avcodec/bitstream_filters: check the input argument of av_bsf_get_by_name() for NULL [16:16:41 CEST] <cone-910> ffmpeg 03James Almer 07master:d228df6ff359: cmdutils: print a more descriptive error message in show_help_bsf() when no bsf is specified [16:35:51 CEST] <JEEB> ubitux: so like this basically https://github.com/jeeb/ffmpeg/commit/67a1801cf0a35b49596ab3b80cdbe1a14b754… ? [16:36:33 CEST] <ubitux> s/fixup/fix/ [16:36:36 CEST] <ubitux> LGTM otherwise [16:36:41 CEST] <ubitux> JEEB ^ [16:37:14 CEST] <JEEB> https://github.com/jeeb/ffmpeg/commit/691d8011ca8594a0309a8f9cae030b64d731d… [16:37:18 CEST] <JEEB> and done :) [16:42:04 CEST] <cone-910> ffmpeg 03Jan Ekström 07master:eb94ec325794: lavfi/nlmeans: fix aarch64 assembly with clang [16:51:30 CEST] <JEEB> I wonder if this is android-specific http://up-cat.net/p/878cd75d [19:03:30 CEST] <tmm1> JEEB: seems like it, maybe make an issue on the ndk github repo [19:47:09 CEST] <atomnuker> kierank: on second though no, I think I'll move to Madrid [19:48:36 CEST] <atomnuker> better language, no stuck up attitude towards english, more non-stop flights to places I'd want to visit, cheaper, less paperwork [19:49:36 CEST] <atomnuker> and if mozilla ever decides to fire its video compression team I can still find a job there as a physicist, since that's where the main software/research work is done on ITER [00:00:00 CEST] --- Sun Jul 29 2018

1 0

ffmpeg.log.20180728
by burek 29 Jul '18

29 Jul '18

[00:24:31 CEST] <benbro> if I have X number of virtual cores on google cloud platform [00:24:50 CEST] <benbro> transcoding from one format to hls will use all cores? [00:25:27 CEST] <benbro> or maybe there is a point where it's a waste [00:27:14 CEST] <Hello71> encoding is not embarrassingly parallelizable, no [00:27:53 CEST] <furq> there are diminishing returns with more cores [00:28:11 CEST] <furq> i assume this is for vod and not a live input [00:28:39 CEST] <benbro> furq: yes, not realtime [00:28:51 CEST] <benbro> I'm currently using 8 vCPUs [00:29:13 CEST] <benbro> so I should compare encoding time of the same file with 4 cores? [00:29:36 CEST] <furq> i expect it'll be slightly more than half as fast [00:29:37 CEST] <benbro> Hello71: so it's not parallelizable? [00:29:44 CEST] <furq> no it's parallelisable [00:29:48 CEST] <Hello71> that's not what I said. [00:29:52 CEST] <furq> right [00:30:22 CEST] <furq> there are (somewhat) noticeable overheads involved in parallelising it [00:30:31 CEST] <furq> which is why you get diminishing returns [00:30:35 CEST] <benbro> so if 4 cores will take 10 minutes to transcode, 8 cores should be a bit more than 5 minutes? [00:30:42 CEST] <furq> i would expect so [00:30:51 CEST] <benbro> thanks [00:31:04 CEST] <benbro> and what if top show that only 50% of the cpu work? [00:31:14 CEST] <furq> then you've got a bottleneck somewhere else [00:31:35 CEST] <benbro> where? [00:31:41 CEST] <furq> shrug [00:31:42 CEST] <benbro> I'm only using ffmpeg inside docker [00:31:45 CEST] <furq> most likely decoding or filtering [00:31:59 CEST] <benbro> not using filters [00:32:04 CEST] <benbro> decoding is not multi-core? [00:32:06 CEST] <furq> are you not rescaling [00:32:32 CEST] <benbro> I am [00:32:36 CEST] <furq> well yeah that's a filter [00:32:38 CEST] <benbro> to 3 resolutions [00:32:39 CEST] <benbro> ok [00:32:54 CEST] <furq> the scale filter is singlethreaded so that's probably the culprit [00:33:11 CEST] <benbro> maybe I should transcode all 3 resolutions in parallel [00:33:15 CEST] <furq> yeah i was just typing that [00:33:22 CEST] <benbro> cool. I'll try it [01:28:11 CEST] <duriangray> does anyone know how to resolve this issue: RTMP_ReadPacket, failed to read RTMP packet header [01:28:18 CEST] <duriangray> Invalid data found when processing input [01:28:31 CEST] <duriangray> when i use ffmpeg to pull in a rtmp feed [02:27:45 CEST] <duriangray> for some reason ffmpeg is working on my mac, but not on my ubuntu vps. any ideas? [02:29:05 CEST] <DHE> going to have to be a LOT more specific than that [02:32:05 CEST] <duriangray> ok i think it has to do with the version [02:32:36 CEST] <duriangray> running apt-get install ffmpeg in ubuntu gave me ffmpeg version 2.8.14-0ubuntu0.16.04.1 [02:32:52 CEST] <duriangray> but on my mac ive got ffmpeg version 4.0 Copyright (c) 2000-2018 the FFmpeg developers [02:33:42 CEST] <DHE> that is a rather old version... [02:34:02 CEST] <tdr> unless your linux is pretty dated, you should get a 3.2.x or higher [02:35:13 CEST] <duriangray> ya that was weird. im running ubuntu 16.04 on a scaleway vps [02:35:25 CEST] <duriangray> anyways, compiling from source and hoping that resolves my issues [02:35:32 CEST] <duriangray> spent all afternoon on this bug ugh [03:12:49 CEST] <rasten33> good luck duriangray [03:14:01 CEST] <DHE> even if it's not pretty dated, git version builds pretty well on centos6 (circa 2010 distro) [03:17:01 CEST] <duriangray> Detected librtmp style URL parameters, these aren't supported by the libavformat internal RTMP handler currently enabled. See the documentation for the correct way to pass parameters. [03:17:08 CEST] <duriangray> that is the new error i mgetting :( [03:36:04 CEST] <duriangray> Anyone know what this is: Invalid UE golomb code [03:55:40 CEST] <Soni> can I coredump ffmpeg, reboot, and load the coredump? [04:06:16 CEST] <Soni> (for resumable conversions and stuff) [08:07:54 CEST] <MeiR> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [08:07:54 CEST] <MeiR> or maybe this blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/ [09:12:51 CEST] <eldritch1> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [10:57:40 CEST] <codebam> Hey, so I cut a clip in ffmpeg with -ss and -t. It plays fine using mpv, vlc, or other ffmpeg players but using the default Android media player the audio is off by nearly an entire second [10:57:45 CEST] <codebam> how can I fix that? [10:58:00 CEST] <codebam> I didn't re-transcode, it was a copy [10:58:22 CEST] <codebam> I transcoded the audio to AAC though [10:59:00 CEST] <JEEB> vlc doesn't use FFmpeg's mp4 reader though [10:59:42 CEST] <JEEB> also another thing you could test is firefox's mp4 playback, which knowingly doesn't support some features, but still manages to keep A/V sync because it doesn't muck with the timestamps [11:00:01 CEST] <codebam> JEEB: works in firefox [11:00:23 CEST] <codebam> but the audio doesn't start for a second or so [11:00:42 CEST] <codebam> so I'm guessing that's the issue, but why is FFmpeg doing that? [11:01:06 CEST] <codebam> if you want, here's the video I'm referring to [11:01:11 CEST] <codebam> https://cytube.nsupdate.info/clip.mp4 [11:01:18 CEST] <codebam> also it's funny lmao [11:01:20 CEST] <JEEB> if you told it to copy the video then it can't really cut at anything else than random access points [11:01:32 CEST] <JEEB> of course the audio not starting but later is funky [11:02:14 CEST] <JEEB> you can try moving the -ss to the point of the video where the random access picture is at and see if it adds the "unnecessary" [11:02:17 CEST] <JEEB> audio there now [11:02:18 CEST] <codebam> JEEB: well yeah but shouldn't it get the audio time right? [11:02:29 CEST] <JEEB> yes, but if that's "unnecessary" audio :D [11:02:32 CEST] <codebam> wait what do you mean? [11:02:38 CEST] <JEEB> if your cut point is later [11:02:45 CEST] <codebam> so move it to where the audio cuts in? [11:02:59 CEST] <JEEB> the video cut point (aka where it could cut the video) [11:03:04 CEST] <JEEB> and thus the audio is not "unnecessary" [11:03:12 CEST] <JEEB> I'm just guessing what ffmpeg.c does [11:03:28 CEST] <codebam> oh, okay. how do I know what the cut point is? [11:03:43 CEST] <codebam> is there some way for me to check what the nearest cutpoint is and cut at that? [11:05:19 CEST] <JEEB> you can -show_packets with ffprobe I think and then filter for the "keyframe" flag? I don't remember the exact stuff [11:05:45 CEST] <JEEB> but looking at the Firefox output you should be able to figure it out [11:05:50 CEST] <codebam> oh okay, well anyways I'll keep moving it around until I get it [11:05:55 CEST] <codebam> a few ms off won't hurt [11:05:59 CEST] <JEEB> as in, how much "extra" video before the cut point it is [11:06:07 CEST] <codebam> yeah exactly [11:07:00 CEST] <codebam> thanks JEEB [11:17:28 CEST] <JEEB> codebam: but basically what you're dealing with is that player not handling mp4 correctly most likely :) [11:19:46 CEST] <codebam> JEEB: yeah lol, that's crazy that the android media player doesn't play mp4's properly [11:20:10 CEST] <codebam> I fixed it by cutting it 2 seconds later [11:20:12 CEST] <JEEB> for web streaming they just separated their player completely from mainline android because a lot of vendors wouldn't update [11:20:27 CEST] <JEEB> https://github.com/google/ExoPlayer/ [11:20:33 CEST] <codebam> oh, interesting [11:20:42 CEST] <JEEB> so now most android video streaming apps use that [11:21:26 CEST] <JEEB> also I really like it when people seem to add FFmpeg features with the code somehow converted into java there [11:21:27 CEST] <codebam> oh right okay, I wonder if the bug I'm seeing is in exoplayer or mediaplayer [11:21:53 CEST] <JEEB> (without mentioning that the code originally is from FFmpeg) [11:22:04 CEST] <codebam> JEEB: haha I see that with other things too. someone rewrote corelibs in java for a stupid homescreen launcher [11:22:29 CEST] <codebam> I found out when I did rm -rf Downloads/* and it deleted all the files in /sdcard [11:23:54 CEST] <JEEB> well rewriting is OK, it's just that usually it's stuff that you can compare to the original C :D [11:24:04 CEST] <JEEB> like, you can clearly see the "inspiration" [11:24:32 CEST] <codebam> ohh yeah [11:25:00 CEST] <JEEB> and that's all OK, just that people generally don't mention what they've done [11:25:21 CEST] <JEEB> they just present it as new, original code [11:50:35 CEST] <hrvoje> alec: you're welcome, and don't blindly divide by 90000, follow Mavrik's advice :)) [12:38:07 CEST] <revi21> Hey, I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/ [20:53:59 CEST] <Li> How can this command syntax modified to prevent/avoid original files overwritting for z in '*mp4'; do ffmpeg -i $z -an -c copy $z;done [20:55:10 CEST] <poutine> for z in '*mp4'; do ffmpeg -i $z -an -c copy "vidonly-${z}";done [00:00:00 CEST] --- Sun Jul 29 2018

1 0

ffmpeg-devel.log.20180727
by burek 28 Jul '18

28 Jul '18

[00:21:58 CEST] <atomnuker> do we have anything that currently miscompiles and failes in some fate test? [00:24:13 CEST] <jamrial> a few tests with msvc 2015 and 2017 [00:24:42 CEST] <jamrial> also what looks like false possitive valgrind failures: http://fate.ffmpeg.org/report.cgi?time=20180726173832&slot=x86_64-archlinux… [00:29:12 CEST] <nevcairiel> the 2017 tests are fixed in a future msvc release [00:29:17 CEST] <nevcairiel> i reported them and got them fixed [00:30:02 CEST] <nevcairiel> not sure what their timeline for the next release it [09:23:48 CEST] <JEEB> lol [09:23:59 CEST] <JEEB> "DTS > PTS is OK because https://devstreaming-cdn.apple.com/videos/streaming/examples/bipbop_16x9/ge… does it" [09:33:57 CEST] <kierank> JEEB: LOL [09:34:17 CEST] <JEEB> yes, I got a fat laugh out of it [09:35:07 CEST] <JEEB> """allowed and works fine""" [09:35:32 CEST] <kierank> Does it actually do that? [09:36:10 CEST] <JEEB> I looked at that TS file and I can see DTS > PTS in the graph [09:36:15 CEST] <JEEB> DVBInspector <32 [09:36:18 CEST] <JEEB> *<3 [09:36:56 CEST] <kierank> Should post that on video-dev [09:37:33 CEST] <kierank> I assume DTS < pcr as well, that's usually the case on these shitty web files [09:38:26 CEST] <JEEB> I'll double-check to make sure it's not just my lack of caffeine [09:39:17 CEST] <JEEB> ok, PCR < DTS at least [09:39:31 CEST] <JEEB> then PTS can of course be before PCR [09:43:18 CEST] <JEEB> kierank: https://kuroko.fushizen.eu/screenshots/apple_mpegts/nice_timestamps_there.p… [09:43:48 CEST] <JEEB> PCR and DTS are monotonically rising and PCR < DTS [09:43:55 CEST] <JEEB> then PTS plays a game around them [09:44:08 CEST] <kierank> the fuck [09:44:36 CEST] <kierank> reminds me what thierry says "these guys don't know what a DTS is" [10:07:21 CEST] <JEEB> michaelni: thanks for running full FATE on that, I did notice some other things with "ismv" in name, but it was late and I didn't figure out how to run them (unlike `make fate-movenc` which I knew of) [12:33:24 CEST] <thardin> quick heads-up: I'm looking into adding an option for qt-faststart for the peertube folks to probe a file for its faststart-ness [12:36:25 CEST] <JEEB> meanwhile I think I'll be postin' patches fixing the sub2video mess with filter chain re-inits [12:36:50 CEST] <JEEB> since it seems like my initial fix only worked well enough with things that contain EOF [12:38:06 CEST] <kierank> JEEB: can you post in video-dev that thing [12:38:09 CEST] <kierank> frankly it's a disgrace [12:38:12 CEST] <kierank> I want to troll web poeple [12:38:34 CEST] <thardin> trolling webdevs is always good [12:38:37 CEST] <JEEB> I'll do that after $dayjob [12:38:42 CEST] <JEEB> because yes, lol [12:38:53 CEST] <JEEB> and then people say their implementations are OK "because apple is doing it too" [12:39:03 CEST] <thardin> my old workplace is trying to make a frame-accurate video editor on the web [12:39:32 CEST] <JEEB> thardin: ooh, sounds like fun. daiz was IIRC testing which web video apis failed at frame-exactness (many) [12:39:56 CEST] <thardin> yeah my initial reaction was like "isn't position a float in the web video api?" [12:40:12 CEST] <thardin> and like, I doubt they deal with audio and video starting at different times [12:41:22 CEST] <thardin> I think they're trying to get involved in the web video circus to try and get it improved [12:41:40 CEST] <thardin> I remain skeptical [12:42:15 CEST] <kierank> JEEB: probably good, will annoy the valley types [12:42:28 CEST] <kierank> JEEB: I might email thierry with that picture [12:42:34 CEST] <JEEB> :D [12:43:16 CEST] <atomnuker> "What are these issues so we can fix them?" [12:43:19 CEST] <atomnuker> WTF [12:43:29 CEST] <atomnuker> literaly in the same sentence above I described them [12:43:33 CEST] <atomnuker> can he not read? [12:43:43 CEST] <atomnuker> its not a long sentence either [13:24:38 CEST] <jdarnley> How can I make ubuntu tell me where the upstream source for a package is? I want to know where indent comes from. [13:58:59 CEST] <thardin> are there fragmented mov/mp4 file samples somewhere? [14:04:37 CEST] <thardin> nm, discovered -frag_size [14:08:55 CEST] <cone-144> ffmpeg 03hwren 07master:d645e0d6c1f2: lavc: add AVS2/IEEE 1857.4 parser [14:08:56 CEST] <cone-144> ffmpeg 03hwren 07master:b7b7b8e8a1ab: lavf: add avs2 fourcc [14:08:57 CEST] <cone-144> ffmpeg 03hwren 07master:5985a1bf7233: lavc, doc, configure: add avs2 video decoder wrapper [14:27:45 CEST] <thardin> is it possible to add a list of files to test inside fate? like if I can separate a bunch of samples into two classes and want to make sure they remain so separated [14:28:17 CEST] <thardin> perhaps a normal shell for loop is enough [15:52:01 CEST] <thardin> is mov-frag-encrypted supposed to fail? [15:52:33 CEST] <jamrial> no [16:12:59 CEST] <thardin> perhaps a rebase will sort it [16:13:12 CEST] <jamrial> atomnuker: can you calm down? why every time i open an email of yours i read only angry rants? [16:13:47 CEST] <jamrial> seriously, i swear you lose your cool for the stupidest shit [16:14:35 CEST] <atomnuker> I thought I didn't this time? [16:14:48 CEST] <gnafu> jamrial: I understand he's been without sleep and in a heatwave, so there's that. [16:14:54 CEST] <gnafu> I can only imagine how miserable that must be. [16:15:05 CEST] <jamrial> re-read the email you wrote that i replied to [16:15:11 CEST] <gnafu> (Not that you aren't generally angry, atomnuker ;-).) [16:17:31 CEST] <cone-144> ffmpeg 03James Almer 07master:536bcc30e04a: avcodec: add missing files missed in previous commits [16:23:35 CEST] <atomnuker> I think BBB's email was angrier tbh [16:23:43 CEST] <BBB> huh what? [16:23:48 CEST] <BBB> I wasnt angry at all [16:24:01 CEST] <BBB> I thought I explained myself really well, at least I tried [16:24:31 CEST] <BBB> if I mis-explained myself or I said something that is scientifically unsound or morally wrong, please let me know, that wasnt my intention at all [16:24:56 CEST] <atomnuker> well my intention wasn't to sound aggressive either, I just made it clear that mistakes were made and it sucks [17:08:20 CEST] <BBB> We don't commit such huge patches without at least some form of review, *ahem* libmpfilter *ahem* *cough* [17:11:18 CEST] <atomnuker> I can't even find a reference to mpfilter anywhere at any time in our repo [17:11:29 CEST] <atomnuker> so I assume this must have been before my time [17:12:00 CEST] <BBB> it was the mplayer avfilter lookalike that was committed to libavfilter because [17:16:49 CEST] <atomnuker> did someone rewrite git history to remove it? [17:16:50 CEST] <jamrial_> atomnuker: it was like ten filters, all gpl, awfully glued to lavfi, that all had to be ported to native ones before they could be removed because people were against removing things without a 1:1 replacement [17:17:11 CEST] <jamrial_> check vf_pp7 and similar, or grep for MPlayer in the libavfilter folder [17:17:29 CEST] <BBB> I think it has left scars on our community [17:17:35 CEST] <BBB> if you werent there, its probably better [17:17:41 CEST] <BBB> it was really awful [17:17:52 CEST] <BBB> I think its the thing that sparked the libav fork [17:17:55 CEST] <BBB> iirc [17:18:04 CEST] <jamrial_> i wasn't there when they were added, but i was there when they were removed. it was a nice chunk of code gone [18:11:43 CEST] <cone-144> ffmpeg 03James Almer 07master:7ca892b7e5ca: fate: remove unnecessary reference file for fate-encryption-info [19:12:39 CEST] <atomnuker> jamrial_: honestly, who's side are you on? [19:13:01 CEST] <atomnuker> how are people supposed to point out what's wrong with the code when its already in the repo? [19:13:13 CEST] <jamrial_> the side of having a discussion, not saying "i'm going to revert it because i think it's wrong" [19:13:17 CEST] <atomnuker> yesterday you were telling me to post the patch now you don't want it [19:13:47 CEST] <atomnuker> we can have a discussion and come up with a patch people are happy with that can then be pushed [19:14:08 CEST] <atomnuker> no need to pollute the git history with dozens of fixes [19:14:20 CEST] <jamrial_> [20:57:01 CEST] <atomnuker> I'm making a patch and explaining what went wrong and how to fix it, if anything it'll raise a discussion and maybe a patch to fix it without reverting [19:14:46 CEST] <jamrial_> your own words, and what i expect to happen. discussions to avoid reverting are happening [19:14:50 CEST] <atomnuker> yes, but pedro's objections have been unsubstatial [19:14:58 CEST] <jamrial_> if no solution is found, then reverting is an option [19:15:18 CEST] <atomnuker> the solution is to revert so we can start clean [19:15:52 CEST] <atomnuker> 3 times I've had to repeat the objections to pedro, is he even listening? [19:16:56 CEST] <atomnuker> I don't see how the code can be saved at all, its rubbish, he'll fucking keep objecting and the code will stay because he won't fix it! [19:17:03 CEST] <atomnuker> this is what might happen [19:17:17 CEST] <atomnuker> especially with the custom float to uint8 conversion [19:19:45 CEST] <jamrial_> if you list all the issues instead of saying "there are too many to list", then he could being trying to address them [19:21:37 CEST] <jamrial_> i'm not against a revert. i'm against a revert in 24 hours when the mentor is still disagreeing [19:25:19 CEST] <atomnuker> it wouldn't have been 24 hours, its more like 36, I wouldn't revert at midnight... [19:25:32 CEST] <atomnuker> and maybe the mentor would accept the situation if I wasn't alone [19:26:08 CEST] <atomnuker> this will take time to clean up and even then it'll be crap, what a mess [19:26:27 CEST] <kierank> you don't need to be so aggressive on the mailing list like it's a life or death situation [19:27:32 CEST] <jamrial_> atomnuker: you're not alone. BBB and j-b are also against this filter in its current state [19:28:01 CEST] <j-b> I just claim that it is currently non-free. [19:28:10 CEST] <j-b> and should be gplv3, because of tensorflow [19:29:48 CEST] <atomnuker> I am alone in that I think it should be reverted [19:31:38 CEST] <atomnuker> kierank: now that the code is committed the author can just endlessly stall and get away with anything [19:31:57 CEST] <j-b> I agree with you, because it shouldn't be in FFmpeg, but that's not my call [19:32:12 CEST] <jamrial_> no, it can't stay like this for the 4.1 release, so it's either fixed before that, or removed before that [19:32:17 CEST] <j-b> Objectively, i can just speak about the legality and the challenges [19:32:17 CEST] <atomnuker> it isn't life or death, its living with shitty code in our repo [19:32:38 CEST] <j-b> but, I think that you are pushing too many 'features' that should be done outside. [19:32:41 CEST] <kierank> 7:31:38 PM <"atomnuker> kierank: now that the code is committed the author can just endlessly stall and get away with anything [19:32:44 CEST] <kierank> that's the whole point of maintainers [19:33:03 CEST] <kierank> to force crap in then block anyone from removing it [19:33:31 CEST] <atomnuker> well he isn't a maintainer, he didn't get a review, he just pushed it thinking it was good enough [19:34:19 CEST] <jamrial_> this is a gsoc project, and he's the mentor [19:34:36 CEST] <JEEB> kierank: thankfully video-dev seemed to mostly WTF about those timestamps [19:35:30 CEST] <atomnuker> even worse, its gsoc code [19:39:55 CEST] <atomnuker> custom pixel format conversion code... its like he hasn't even read the yearly discussion we have as to why we very clearly never ever ever do that [19:50:04 CEST] <BBB> I think hes a more recent contributor so he would have missed all of that [19:57:11 CEST] <kierank> you know the right way to do this would be to write a policy document [19:57:13 CEST] <kierank> at vdd [19:57:39 CEST] <kierank> but yes I dislike inline pixel format conversion code as well [19:58:09 CEST] <BBB> yes lets discuss at vdd, that has always solved everything :( [19:59:12 CEST] <kierank> BBB: hence "the right way" [19:59:31 CEST] <BBB> sarcasm is difficult to convey over IRC [19:59:39 CEST] <BBB> I was being sarcastic [20:00:05 CEST] <BBB> you know, atomnuker has a point. weve always complained about thing in mpegvideo and you know how difficult it is to get things past maintainer review [20:00:13 CEST] <BBB> getting rid of old clutchy stuff is impossible [20:01:54 CEST] <jamrial_> yes, but giving a 24hs ultimatum is pushing it a bit [20:02:08 CEST] <jamrial_> saying "this needs to be fully fixed or removed before the next release is tagged" is acceptable [20:02:20 CEST] Action: BBB shuffers thinking of ffserver [20:02:24 CEST] <BBB> *shudders [20:04:07 CEST] <jamrial_> that's good example. ffserver one had a "must be fixed before the next bump" limit, and when it was not achieved, it was removed [20:04:10 CEST] <jamrial_> so do the same here [20:04:36 CEST] <jamrial_> the code as is can't go into ffmpeg 4.1 or distros will hate us [20:04:41 CEST] <jamrial_> so that's the time limit [20:05:52 CEST] <jamrial_> but please, don't be aggresive. how else do we expect contributors to stay around after gsoc, if their first project is trashed like this? [20:10:36 CEST] <BBB> nobody has as of yet responded to my question about merging filters with similar interfaces (if the only diff is the coefficients) [20:13:34 CEST] <durandal_1707> i hereby object nn filter removal, please do not push it [00:00:00 CEST] --- Sat Jul 28 2018

1 0

ffmpeg.log.20180727
by burek 28 Jul '18

28 Jul '18

[00:33:52 CEST] <duriangray> hi [00:34:30 CEST] <duriangray> hi - So i am piping out: ffmpeg -i http://source.com -c copy -f mpegts udp://127.0.0.1:9000 [00:34:47 CEST] <duriangray> how do i pull it in from another server? [01:17:45 CEST] <lyncher> poutine: yes, I'm trying to add SEI messages (itu35) with 608 captions. right now I'm not even able to transcode a h264->h265 and keep the captions [03:31:17 CEST] <rasten33> hm [03:32:36 CEST] <rasten33> yyu believe in the holocaust? [04:51:46 CEST] <codebam> how do I transcode the audio from another video into this video? [04:51:51 CEST] <codebam> I'd use copy for the video format [04:51:57 CEST] <codebam> but how do I do the audio [04:52:12 CEST] <furq> -i foo -i bar -map 0:v -map 1:a [04:52:30 CEST] <codebam> oh cool I can specify another input [04:52:32 CEST] <codebam> thanks [05:25:46 CEST] <linuxmaster1> rasten33: we are the holocaust [06:07:39 CEST] <rasten33> lolocauster [06:07:53 CEST] <rasten33> the roller casters f death [06:07:59 CEST] <rasten33> funny ass [06:08:50 CEST] <Cracki> did you know having questions about that in your country is... dangerous? [06:08:54 CEST] <rasten33> fuckin lies, the h0l0csust [06:09:08 CEST] <rasten33> i was jailed already [06:09:11 CEST] <rasten33> 18 mnoths [06:09:46 CEST] <Cracki> make informative postcards/flyers and distribute them. [06:09:58 CEST] <rasten33> nah [06:10:07 CEST] <Cracki> there might be more consequences for that though [06:10:13 CEST] <rasten33> hehe [06:10:20 CEST] <rasten33> its silly [06:10:33 CEST] <rasten33> smart flks know whts up [06:10:38 CEST] <rasten33> stupid peple believe lies [06:10:51 CEST] <Cracki> silly is when wikipedia "cites" sources on the second world war that were published in 2010 [06:11:25 CEST] <rasten33> if yu can talk abut it withut giong to jail [06:11:27 CEST] <rasten33> d it [06:11:36 CEST] <Cracki> the chain of retellings for that time span must be impenetrable. I'd cite publications from temporally closer. [06:11:51 CEST] <rasten33> it is just silly [06:12:02 CEST] <rasten33> gas chabers with glas windws [06:12:08 CEST] <Cracki> are you into microcontrollers perhaps? [06:12:16 CEST] <rasten33> noo [06:12:32 CEST] <Cracki> might be something you could enjoy [06:12:51 CEST] <rasten33> if yu believe bullshit hlocaust you deserve your slavery [06:12:52 CEST] <Cracki> there are different kinds. my personal favorite is the stm32. it's an arm cortex-m. [06:13:26 CEST] <Cracki> so... what are you doing with ffmpeg? [06:13:32 CEST] <Cracki> anything fun or interesting? [06:13:44 CEST] <rasten33> testing motion interpolationo [06:13:51 CEST] <Cracki> good stuff! [06:13:52 CEST] <rasten33> greets t 8200 [06:14:40 CEST] <rasten33> i'd like a jew wife if i can find ne [06:15:52 CEST] <rasten33> n the ther hand id like t kill yu [06:16:15 CEST] <rasten33> kike [06:16:43 CEST] <Cracki> what are you trying to achieve with this blunt approach? [06:17:12 CEST] <rasten33> intelligence selectiono [06:17:25 CEST] <rasten33> i fear with jew control stupid will procreate [06:17:51 CEST] <rasten33> i dnt care who wins [06:17:59 CEST] <rasten33> i just want mre smart [06:20:24 CEST] <rasten33> well [06:20:27 CEST] <duriangray> what country r u from>? [06:20:32 CEST] <rasten33> mars [06:20:38 CEST] <rasten33> optimally we kill all jews [06:20:41 CEST] <rasten33> but barring that [06:21:43 CEST] <duriangray> ??? i am so confused [06:21:51 CEST] <rasten33> jews are evil [06:21:55 CEST] <duriangray> what does jews have to do with ffmpeg? [06:21:56 CEST] <rasten33> they did communism [06:22:03 CEST] <rasten33> and ww1 and ww2 [06:22:05 CEST] <rasten33> they are satan [06:22:23 CEST] <rasten33> i dunno this asshle started the cnversationo [06:35:38 CEST] <rasten33> well cunt [06:35:52 CEST] <rasten33> hows the kikedm ding [06:36:31 CEST] <rasten33> lol [06:36:38 CEST] <rasten33> fuckin kikes [07:01:20 CEST] <rasten33> you fucks did 9/11 [07:01:43 CEST] <rasten33> your jew courts are blocking the victim lawsuits [07:02:17 CEST] <rasten33> you did the USS LIberty attack [07:02:22 CEST] <rasten33> and the JFK assassinationo [07:02:26 CEST] <rasten33> you are satan [07:04:43 CEST] <rasten33> 6 [07:29:10 CEST] <linuxmaster1> Happy Sysadmin's Day! [08:19:32 CEST] <codebam> linuxmaster1: cool! about to tell all my friends [08:19:42 CEST] <codebam> happy sysadmin's day to you too [08:57:08 CEST] <g0> How does one actually enable the kmsgrab device at configure time? 'configure' does not have any word about it other than ./configure:kmsgrab_indev_deps="libdrm" [08:57:55 CEST] <furq> generally if there's no --enable switch then it's enabled by default as long as the dependencies are met [08:58:04 CEST] <furq> so i guess make sure that configure can find libdrm [09:02:55 CEST] <g0> ah so I needed --enable-libdrm [12:05:32 CEST] <Guest29467> Hello everybody [12:06:20 CEST] <Guest29467> I have a big problem on my project using ffmpeg [12:06:41 CEST] <Guest29467> I have one video with crossfade effect and i want add text on this video (drawtext). However when i add a filter text, he remove a crossfade effect in the final video. [12:07:12 CEST] <Guest29467> command with crossfade : ffmpeg -i first.mp4 -i second.mp4 -filter_complex "[0:v]trim=start=0:end=2,setpts=PTS-STARTPTS[0_clip_1]; [0:v]trim=start=2:end=3,setpts=PTS-STARTPTS[fadeoutsrc_0]; [fadeoutsrc_0]format=pix_fmts=yuva420p,fade=t=out:st=0:d=1:alpha=1[fadeout_0]; [fadeout_0]fifo[fadeoutfifo_0];[1:v]trim=start=1,setpts=PTS-STARTPTS[1_clip_2]; [1:v]trim=start=0:end=1,setpts=PTS-STARTPTS[fadeinsrc_1]; [12:07:31 CEST] <Guest29467> and command drawtext : ffmpeg -i videoWithCrossfade.mp4 -filter_complex "/Windows/fonts/arial.ttf':text='hello world!':fontcolor=white:fontsize=40:box=1:boxcolor=red @0.5:boxborderw=10:x=500:y=500" output.mp4 [12:08:53 CEST] <Guest29467> https://pastebin.com/j1tfs7s3 [12:12:46 CEST] <Guest29467> Hello everybody [12:12:50 CEST] <Guest29467> I have a big problem on my project using ffmpeg [12:12:59 CEST] <Guest29467> I have one video with crossfade effect and i want add text on this video (drawtext). However when i add a filter text, he remove a crossfade effect in the final video. [12:13:12 CEST] <Guest29467> https://pastebin.com/j1tfs7s3 [12:24:44 CEST] <Guest29467> Hello everybody. I have a big problem on my project using ffmpeg. I have one video with crossfade effect and i want add text on this video (drawtext). However when i add a filter text, he remove a crossfade effect in the final video. [12:24:49 CEST] <Guest29467> https://pastebin.com/j1tfs7s3 [12:25:05 CEST] <Guest29467> thanks for your help [18:50:08 CEST] <peloverde> Does anyone have a recording (flv or pcap) of elemental's scte-35 rtmp output? [18:51:39 CEST] <JEEB> nope [19:11:17 CEST] <serialnuts> hi I am getting a few errors with ffmpeg while trying this out. Could anyone please help me out pointing out where the syntax is wrong on my part? [19:11:57 CEST] <serialnuts> ffmpeg -threads 0 -probesize 100M -analyzeduration 100M -i "${filename}" -c:v libx265 -preset medium -x265-params "pass=2:crf=28" -c:a libmp3lame -q:a 9 "${filename%%.*}"_hevc.mkv [19:14:02 CEST] <serialnuts> it breaks whenever I add an additional argument to the -x265-params part. For intance if I leave it at crf=28 (and skip pass=2) without quotes it works [19:16:53 CEST] <serialnuts> pwd [19:17:06 CEST] <serialnuts> I think i solved it. Thanks anyway :] [19:17:46 CEST] <serialnuts> I used the pass option as an argument to ffmpeg instead of passing it to x265 ass a parameter [20:25:43 CEST] <emilsedgh> Hi. I have a list of images and I want to create a movie out of them. I can do it easily. The only thing is, I have timestamps for them. i want them to appear in specific times. Is there anyway I can do that? [20:26:31 CEST] <emilsedgh> So basically I know i1 should appear at t1 and i2 should appear at t5 (so basically i1 should stand still from t1 to t4) [20:26:34 CEST] <emilsedgh> Does that even make sense? [20:26:46 CEST] <JEEB> &38 [20:27:31 CEST] <furq> emilsedgh: make a cfr file with ffmpeg and then remux it with mkvmerge and a timecode file [20:27:34 CEST] <furq> https://manpages.debian.org/stretch/mkvtoolnix/mkvmerge.1.en.html#EXTERNAL_… [20:27:51 CEST] <emilsedgh> furq: thanks for the clue. I will now look into this. [20:31:55 CEST] <emilsedgh> furq: crf of cfr? where can i find a bit of more documentation about it? [20:32:03 CEST] <furq> cfr as in constant framerate [20:32:44 CEST] <emilsedgh> Thanks furq [20:34:18 CEST] <furq> timelineeditor from l-smash will also work if you want an mp4 [20:34:33 CEST] <furq> apparently it supports mkvmerge timecode formats 1 and 2 [23:09:52 CEST] <hdqn> hello [23:10:30 CEST] <hdqn> running `ffmpeg -f x11grab -an -i :0.0 -f rawvideo - | ffplay -f rawvideo -i -` [23:11:26 CEST] <hdqn> I get this: https://paste.xinu.at/P43B/ [23:11:46 CEST] <hdqn> trying to capture my x11 desktop and live preview [23:12:42 CEST] <rasten33> using a compositor? [23:12:45 CEST] <hdqn> yes [23:12:50 CEST] <hdqn> compton [23:13:03 CEST] <rasten33> i get probs with compton and x11grab [23:13:23 CEST] <hdqn> is there a different way? I'm just testing this out [23:13:23 CEST] <rasten33> might need to use a different render backend for compton [23:13:35 CEST] <rasten33> i have gkx atm [23:13:39 CEST] <rasten33> glx [23:14:22 CEST] <rasten33> btw i have a small project for anyone who is interested in shaders and compton [23:14:47 CEST] <rasten33> transparency-to-root window with keycolor alpha transparency [23:15:03 CEST] <rasten33> would donate beermoney [23:15:25 CEST] <rasten33> i have the keycolor shader almost working [23:15:32 CEST] <hdqn> oh you mean the compton backend [23:15:38 CEST] <rasten33> yeah [23:15:46 CEST] <hdqn> my backend is glx [23:15:49 CEST] <kepstin> hdqn: when reading raw video, you'll have to set the frame size, pixel format, and framerate [23:16:04 CEST] <hdqn> kepstin: would -re do? [23:16:05 CEST] <kepstin> hdqn: maybe you should put the video into a container when piping it rather than using rawvideo [23:16:20 CEST] <hdqn> how? [23:16:29 CEST] <kepstin> hdqn: by using -f (something other than rawvideo) [23:17:01 CEST] <kepstin> e.g. -f matroska or -f nut would work here, you'll likely also have to specify the video codec [23:17:11 CEST] <kepstin> (both containers should support uncompressed video if you like) [23:17:18 CEST] <hdqn> where can I find the possible formats? [23:18:09 CEST] <hdqn> no go with matroska: https://paste.xinu.at/tiA/ [23:18:09 CEST] <kepstin> hdqn: for now just run `ffmpeg -f x11grab -i :0.0 -c:v rawvideo -f nut | ffplay -i -` [23:18:57 CEST] <kepstin> that was just an issue because you didn't set the video codec, so it defaulted to x264 with high delay [23:19:06 CEST] <hdqn> kepstin: forgot to output to stdout with - :) [23:19:12 CEST] <hdqn> you did I mean [23:19:18 CEST] <hdqn> alright, I have some previe [23:19:21 CEST] <hdqn> s/$/w [23:21:25 CEST] <hdqn> kepstin: thanks, that should get me started [23:24:29 CEST] <rasten33> it works with compton? [23:27:01 CEST] <kepstin> x11grab should work fine with compostors running on x11 [23:27:17 CEST] <kepstin> (it notably won't work on wayland stuff) [23:27:50 CEST] <Hello71> well it will if your application is X [23:28:48 CEST] <kepstin> hmm, I haven't actually seen that work, I get black even when capturing areas with X11 windows like firefox in my testing. [00:00:00 CEST] --- Sat Jul 28 2018

1 0

ffmpeg-devel.log.20180726
by burek 27 Jul '18

27 Jul '18

[00:21:16 CEST] <BtbN> philipl, I'll look at it once I get home next week, no time until then. But if that's the case, there's not much to it for ffmpeg. [00:43:43 CEST] <BtbN> The thing I don't get is why it still happens with librtmp disabled. It's an entirely different codepath [00:43:50 CEST] <BtbN> Or is the --disable for it just broken? hm [00:46:13 CEST] <philipl> BtbN: yeah, not clear if the reconfigure is that interesting or not; I guess it helps us support mid-stream format changes more easily. [00:46:33 CEST] <BtbN> But we already support them just fine? What's new? [00:46:46 CEST] <philipl> We recreate the decoder to do it? [02:43:30 CEST] <cone-457> ffmpeg 03Marcin Gorzel 07master:8b710ea5e7b8: swresample: Use channel count in rematrix initialization [02:43:30 CEST] <cone-457> ffmpeg 03Michael Niedermayer 07master:a37c62026991: avformat/mov: Check default_encrypted_sample before use in mov_read_sample_encryption_info() [02:43:32 CEST] <cone-457> ffmpeg 03Michael Niedermayer 07master:bce4da85e811: swresample/swresample: Fix input channel count in resample_first computation [15:12:26 CEST] <durandal_1707> kierank: will you sponsor lavfi improvements? [15:12:59 CEST] <kierank> Like what [15:13:56 CEST] <durandal_1707> better interface to users [15:37:34 CEST] <cone-987> ffmpeg 03Jun Zhao 07master:790cf9518a37: lavf/tcp: add option to setting Maximum Segment Size [15:37:35 CEST] <cone-987> ffmpeg 03Jun Zhao 07master:a8ce6fb425e0: doc/protocols: documents tcp_mss [18:17:39 CEST] <durandal_1707> so only michaelni is paid for his hard work? [18:22:01 CEST] <kierank> durandal_1707: could pay [18:22:13 CEST] <kierank> need framesync and other nicholas crap gone [18:31:39 CEST] <atomnuker> framesync is fine, what's your problem with it? [18:31:46 CEST] <atomnuker> it makes things simpler for filters [18:32:26 CEST] <atomnuker> I'd really rather not have filters needing to mess with timestamps, framesync does abstract it away nicely [18:34:05 CEST] <atomnuker> the work nicholas has done on lavfi has been alright [18:34:38 CEST] <kierank> variable latency, great [18:34:53 CEST] <kierank> let me know where i can find my time machine [18:35:31 CEST] <atomnuker> or you can stop having something against the person himself and admit that variable latency is needed in some cases, and in such cases having a simpler api wouldn't work [18:35:52 CEST] <durandal_1707> atomnuker: how so? [18:36:15 CEST] <durandal_1707> simpler api should resolve latency issues [18:36:33 CEST] <durandal_1707> basically you would get all frames from input pads at once [18:37:06 CEST] <atomnuker> yes, it will, but suppose you have a filter which refs a frame once given, and oututs it when there's a frame on the second stream which matches the held frame [18:37:23 CEST] <atomnuker> I'm just giving an example of a variable latency multi stream filter [18:38:04 CEST] <atomnuker> I can't think of why you'd like to do that but my point is that filters can sometimes act like encoders and hold frames for variable amounts of time [18:38:57 CEST] <atomnuker> and I don't think a simple API which can guarantee latency of X frames can do the same with such filters [18:39:57 CEST] <atomnuker> I don't mind having a simple API for filters which don't need this, which are just single frame in -> single frame out [18:40:04 CEST] <atomnuker> that's like 80% of lavfi filters already [18:40:44 CEST] <atomnuker> but I don't think that we should be removing code and API which breaks the other 20% or however many there are [18:40:57 CEST] <durandal_1707> this is mainly for overlay filter, which is not single in -> single out [18:42:07 CEST] <atomnuker> yes, the overlay filter does fit into the former category well, but I don't think people should be demonizing framesync but say, adding a mode where it doesn't check PTS, doesn't hold frames, it just always outputs them [18:42:53 CEST] <durandal_1707> i was thinking about having additional api, not removing old one [18:43:23 CEST] <atomnuker> yes, an additional external API is what I was talking about, this is about framesync which is entirely internal [18:43:35 CEST] <kierank> yes but you can't use avfilter without framesync and all the other stuff right now [18:43:43 CEST] <kierank> it's a big monolithic thing [18:43:49 CEST] <atomnuker> so we fix framesync! [18:43:57 CEST] <atomnuker> I didn't say anthing about removing it [18:43:58 CEST] <kierank> it's unfixable [18:44:02 CEST] <atomnuker> it can have a bypass mode [18:44:06 CEST] <atomnuker> anything can have a bypass mode [18:44:19 CEST] <atomnuker> and what do you know about lavfi? you haven't written a single filter [18:45:36 CEST] <kierank> I've tried to use it for real [18:45:40 CEST] <kierank> and had to use undocumented hack after hack [18:45:42 CEST] <rcombs> tangentially, I'd still like a "timestamp heartbeat" concept in a lot of places [18:45:48 CEST] <atomnuker> framesync can let you have frames as soon as they come and not handle variable FPS, synchronous video stream [18:46:14 CEST] <atomnuker> kierank: internally, not externally, framesync isn't even visible to users [18:46:39 CEST] <atomnuker> you don't know what it is, you just know its evil, written by a person you don't like, and you'd go to lengths to remove it just because of this [18:47:10 CEST] <kierank> I do know what it is, and moreso I know it is complely ununderstandable and said person won't allow anyone to touch it [18:47:33 CEST] <kierank> worse still it is reinvention of things which are well understood in multimedia [18:48:01 CEST] <durandal_1707> what things? could you name them? [18:48:14 CEST] <kierank> https://en.wikipedia.org/wiki/Frame_synchronization_(video) [18:48:16 CEST] <kierank> this is a solved problem [18:49:46 CEST] <atomnuker> how else would a filter handle variable fps inputs which need to be timed to be overlaid? framesync handles that for you [18:50:19 CEST] <durandal_1707> simpler api would let user to handle all that framesync stuff [18:50:39 CEST] <kierank> buffer to infinity [18:50:41 CEST] <kierank> that's the best way! [18:50:58 CEST] <atomnuker> yes, I agree, but a more complicated API is needed if you want to have that handled for you [18:51:33 CEST] <atomnuker> and it isn't a reinvention, its an implementation [18:51:35 CEST] <rcombs> that sounds& potentially unsustainable [18:51:51 CEST] <rcombs> what if you never get new input on one of the pads [18:51:52 CEST] <kierank> ask daemon404 about the number of avfilter OOMs they get a day [18:52:10 CEST] <atomnuker> I haven't heard anything about that for 2.5 years [18:52:12 CEST] <kierank> because it just decides to start buffering when it wants [18:52:14 CEST] <rcombs> say, overlay [18:52:55 CEST] <atomnuker> kierank: well, how else to handle input with crap timestamps? [18:52:57 CEST] <rcombs> I think sub2video avoids that by using blank "heartbeat" frames [18:53:05 CEST] <atomnuker> like I said, a simpler api wouldn't need to think about this [18:53:13 CEST] <atomnuker> and I'm okay with it [18:54:53 CEST] <kierank> people who want things to work can actually use it [18:54:57 CEST] <kierank> everyone else can enjoy OOM [18:55:31 CEST] <atomnuker> kierank: how would you handle OOMs? have a limit on how much you can allocate! [18:55:43 CEST] <atomnuker> there's no ideal solution for this problem [18:55:47 CEST] <kierank> yeah there is [18:55:49 CEST] <kierank> drop frames [18:56:02 CEST] <kierank> If I have n input streams coming as vfr [18:56:09 CEST] <kierank> I can't just pick the first one as the master [18:56:12 CEST] <kierank> because if it stops they all stop [18:56:18 CEST] <kierank> and I can't just jump around between all of them [18:56:21 CEST] <kierank> because that's fucked [18:56:29 CEST] <kierank> so what you do is pick a sane underlying cfr framerate [18:56:36 CEST] <kierank> but the vfr cultists won't like that [18:57:02 CEST] <kierank> so we'd rather have a broken framesync doing weird stuff when streams come and go than actually something that works in 99% of cases [18:57:09 CEST] <atomnuker> no, we won't, because VFR has a place in video, though mostly in computers, not broadcast [18:57:29 CEST] <atomnuker> 99% of broadcast cases [18:57:34 CEST] <kierank> noone said anything about broadcast [18:57:39 CEST] <kierank> you just decided to paint that on me [18:57:40 CEST] Action: rcombs looks at subtitles, which are "VFR" [18:57:44 CEST] <atomnuker> you did when you said pick an underlying CFR [18:57:50 CEST] <kierank> yes because the world is cfr [18:57:53 CEST] <kierank> monitors are cfr [18:57:57 CEST] <atomnuker> no they aren't [18:58:00 CEST] <kierank> yes they are [18:58:03 CEST] <atomnuker> computer ones aren't [18:58:05 CEST] <atomnuker> freesync [18:58:09 CEST] <atomnuker> wayland isn't [18:58:10 CEST] <kierank> yes they are what planet do you live on [18:58:12 CEST] <kierank> who has freesync [18:58:14 CEST] <kierank> a bunch of geeks [18:58:19 CEST] <kierank> 99% of the world has cfr monitor [18:58:31 CEST] <rcombs> new iPads are VFR [18:58:39 CEST] <atomnuker> I'm living on a planet where programs don't refresh their windows at 60fps but only when they need to or are told to [18:58:57 CEST] <atomnuker> regardless of what the monitor is doing, capturing my screen yields variable fps [18:58:59 CEST] <kierank> and live pipelines can go back and forwards in time because of variable latency [18:59:05 CEST] <kierank> then you don't understand multimedia [18:59:12 CEST] <kierank> you conflate time of capture with time of presentation [18:59:32 CEST] <atomnuker> time of presentation can be time of capture but with an offset [18:59:43 CEST] <kierank> no it can't [18:59:46 CEST] <kierank> then it has noise [18:59:59 CEST] <atomnuker> not a random offset, but an offset into the future [19:00:05 CEST] <kierank> then how is it vfr [19:00:36 CEST] <atomnuker> the timestamps themselves say to present N timebases into the future [19:00:56 CEST] <kierank> why would N vary [19:01:22 CEST] <kierank> 1/60 + N where N is a constant is cfr [19:01:28 CEST] <atomnuker> because maybe nothing has changed, and capturing a frame right now would be useless and just add overhead [19:01:39 CEST] <kierank> that's orthogonal to capture [19:01:41 CEST] <atomnuker> the timebase doesn't have to indicate the framerate [19:01:47 CEST] <kierank> also orthogonal [19:02:06 CEST] <atomnuker> indeed [19:02:08 CEST] <kierank> live video is cfr whatever the source [19:02:27 CEST] <atomnuker> doesn't have to be, could be a slideshow of frames with variable delay [19:02:45 CEST] <kierank> your monitor still renders them every 60hz [19:02:57 CEST] <durandal_1707> so send patch, to extend framesync to drop frames if it would buffer too much? [19:02:59 CEST] <atomnuker> so, whatever, doesn't have to [19:03:27 CEST] <kierank> durandal_1707: what about fixing variable latency in avfilter pipeline [19:03:28 CEST] <atomnuker> its the player's responsibility to clock them to whatever the compositor says the framerate of the monitor is [19:03:34 CEST] <atomnuker> and that could change per-frame [19:03:43 CEST] <kierank> and if the pipeline has latency that goes forward and backwards how does it know how to bound its latency [20:15:12 CEST] <BBB> haha https://lwn.net/Articles/760142/ [20:15:19 CEST] <BBB> so were not the only ones complaining about this nnnonsense [20:15:46 CEST] <BBB> for ocne I appreciate debians stubbornness [20:26:00 CEST] <durandal_1707> we should allow nn in FFmpeg [20:28:47 CEST] <jamrial> we already do. we even have like 12k lines of weighs with no way to reproduce them, which is what people dislike [20:36:18 CEST] <Gramner> what about making the code take weights as a (non-included) input file? [20:37:08 CEST] <jamrial> it was suggested. nnedi does that, even [20:37:16 CEST] <jamrial> no idea why it wasn't done for this one [20:38:15 CEST] <Gramner> since weights are essentially a binary black box, just because you can stuff them into a c array doesn't make it source code [20:38:39 CEST] <jamrial> it should be reverted and implemented that way, really. i bet the only reason it was commited this way is no one was strict enough to say "don't" [20:39:20 CEST] <JEEB> yes [20:42:53 CEST] <atomnuker> I agree as well [20:43:15 CEST] <atomnuker> we still haven't done a release yet with any NN stuff, right? [20:44:29 CEST] <jamrial> no, we haven't [20:45:28 CEST] <durandal_1707> what about all those vlc tables in source code? you do not have ways to reproduce them either. [20:45:39 CEST] <jdarnley> I wonder how the FSF lawyers would see it? Perhaps they wouldn't have a problem with it because you can build binary X from source Y. [20:46:09 CEST] <BradleyS> licensing aside, i can say as a downstream binary size is a concern for handbrake and probably others [20:46:22 CEST] <BradleyS> one reason we didn't include nnedi back in the day [20:46:57 CEST] <jdarnley> The avisynth plugin? Was it that big? [20:47:04 CEST] <BradleyS> iirc it had something like 12 MiB of weighting information [20:47:24 CEST] <BradleyS> tritical's nnedi, avisynth was a port of it if i recall [20:47:49 CEST] <BradleyS> ah nevermind his original was for avisynth [20:47:57 CEST] <JEEB> yea original was avisynth [20:48:01 CEST] <JEEB> then there was a vapourynth port [20:48:05 CEST] <JEEB> and then that got ported to lavfi [20:49:59 CEST] <atomnuker> so far the only filter I see that we embed DNNs for is srcnn [20:50:05 CEST] <BradleyS> handbrake has had an eedi2 port for ages, wasn't for lack of interest [20:50:14 CEST] <atomnuker> it has 5000 lines of weights, not 12k [20:51:05 CEST] <durandal_1707> there is nnedi based superscaler too [20:52:05 CEST] <atomnuker> oh, and espcn [20:52:19 CEST] <atomnuker> DNNModel* ff_dnn_load_model_native(const char* model_filename) [20:52:21 CEST] <atomnuker> .......... [20:52:39 CEST] <atomnuker> god damn it, who writes in such a fucked up style [20:52:45 CEST] <atomnuker> fucking intel code [20:53:03 CEST] <atomnuker> I'm making a patch to revert everything, this is unacceptable [20:53:19 CEST] <durandal_1707> what's wrong pal? [20:53:53 CEST] <BradleyS> that's organizationism :P [20:55:59 CEST] <durandal_1707> atomnuker: stop! [20:57:01 CEST] <atomnuker> I'm making a patch and explaining what went wrong and how to fix it, if anything it'll raise a discussion and maybe a patch to fix it without reverting [20:58:58 CEST] <durandal_1707> atomnuker: please visit nearest shrink asap! [20:59:19 CEST] <atomnuker> why? [20:59:34 CEST] <atomnuker> we agree that something must be done [20:59:51 CEST] <durandal_1707> but let someone else do it [21:00:03 CEST] <atomnuker> certainly before we make a release, and I don't want a repeat of the 4.0 blocker bugs [21:00:33 CEST] <atomnuker> who else wants to do it then? I don't mind [21:14:51 CEST] <jamrial> atomnuker: go ahead and do it [21:14:53 CEST] <atomnuker> ok, here's the patch if anyone things I should add something to the message: https://0x0.st/sVgR.patch [21:14:57 CEST] <durandal_1707> atomnuker: just forget about it [21:15:28 CEST] <atomnuker> I can't unsee the incorrectly placed asterix [21:15:48 CEST] <jamrial> durandal_1707: stop [21:16:56 CEST] <jamrial> 1mb patch, hah [21:17:10 CEST] <jamrial> ~12k lines for dnn_espcn.h alone [21:18:13 CEST] <durandal_1707> jamrial: please do not tell me what to do [21:18:32 CEST] <jamrial> atomnuker: remove the "As discussed on IRC" part. it was discussed in the ml as well [21:19:12 CEST] <atomnuker> oh wow, you're right, 1mb [21:20:23 CEST] <jamrial> consider just stripping the deleted files to unbloat the patch [21:20:49 CEST] <jamrial> it wont be git am'able, though [21:21:41 CEST] <jamrial> but since it doesn't need testing, just agreement, it wont matter [21:23:39 CEST] <durandal_1707> I will veto this patch! [21:27:22 CEST] <atomnuker> jamrial: k, patch (actually just the cover letter with stats and a message) sent to the ML [21:42:25 CEST] <JEEB> anyone remembers aarch64 asm to give any hints on what to do with https://www.irccloud.com/pastebin/wL2sKCW2/ ? [21:44:41 CEST] <durandal_1707> ask ubitux [21:45:42 CEST] <jamrial> JEEB: sounds like an outdated/buggy assembler? [21:45:56 CEST] <JEEB> NDK r17b clang [21:49:27 CEST] <jamrial> seems to compile fine with http://fate.ffmpeg.org/report.cgi?slot=aarch64-linux-qemu-ubuntu-gcc-4.8&ti… [21:49:40 CEST] <jamrial> we don't have a ndk aarch64 fate client, though [21:50:23 CEST] <JEEB> yea tje gcc still does [21:50:30 CEST] <JEEB> (in NDK even) [21:50:36 CEST] <JEEB> but they're going to be removing that soon [21:52:14 CEST] <atomnuker> I can test with clang-6 [21:55:07 CEST] <ubitux> JEEB: that's strange, we do already have that kind of op in other part of the codebase [21:55:10 CEST] <ubitux> libavcodec/aarch64/vp9mc_neon.S: add x9, x6, w5, uxtw #4 [21:55:17 CEST] <ubitux> does this one compile? [21:55:48 CEST] <JEEB> lemme see [21:56:36 CEST] <jamrial> the dup line it complains about may be not "correct", as well [21:56:49 CEST] <jamrial> it looks different than similar ones in libavcodec files [21:57:25 CEST] <ubitux> i don't have a working toolchain right now, but what you can do is assemble it with a toolchain that works, and look at the generated assembly [21:57:27 CEST] <jamrial> maybe it should be "dup v24.4S, v24.S[3]" [21:57:55 CEST] <ubitux> yup, that might help this one [21:59:15 CEST] <jamrial> what assembler does clang use? a binutils from the gcc 4.8 era doesn't complain, so really odd [22:00:02 CEST] <ubitux> for the sub line, the main diff is "w1" instead of "x1" [22:00:10 CEST] <ubitux> and maybe the fact it's a sub and not a add [22:00:29 CEST] <ubitux> so you may try changing those, just to test the compilation [22:01:34 CEST] <JEEB> did you need the vf_ prefix when disabling filters? [22:02:43 CEST] <durandal_1707> why are you disabling filters? [22:03:42 CEST] <JEEB> because nlmeans doesn't compile? [22:03:55 CEST] <durandal_1707> fix it and post patch? [22:04:12 CEST] <ubitux> JEEB: make libavcodec/aarch64/vp9mc_neon.o [22:04:13 CEST] <jdarnley> JEEB: no [22:04:14 CEST] <JEEB> fuck you too, I was just asked to skip it to build avcodec first which has similar SIMD for VP9 [22:04:15 CEST] <ubitux> or make -k [22:04:26 CEST] <durandal_1707> obviously you only give name [22:04:27 CEST] <JEEB> jdarnley: thank you [22:04:42 CEST] <JEEB> I am fucking tired, I just came back home like 1.5 hours ago [22:04:45 CEST] <JEEB> anything else you want? [22:04:49 CEST] <JEEB> an ice cream? [22:06:01 CEST] <JEEB> ok, got my configure line for aarch64 done... let's see [22:06:15 CEST] <atomnuker> yeah, clang-6 has the same error here on aarch64 [22:06:21 CEST] <ubitux> JEEB: c: cb214809 sub x9, x0, w1, uxtw #2 [22:06:31 CEST] <ubitux> this is how it's supposed to be assembled [22:06:44 CEST] <ubitux> and jamrial is right [22:06:46 CEST] <ubitux> c0: 4e1c0718 dup v24.4s, v24.s[3] [22:06:53 CEST] <ubitux> basically, change these instructions like this [22:06:55 CEST] <ubitux> it should do the trick [22:07:29 CEST] <JEEB> atomnuker: good to know that it's not just NDK [22:08:13 CEST] <ubitux> (got those using objdump on the assembled .o) [22:08:32 CEST] Action: ubitux & [22:09:21 CEST] <durandal_1707> clang usually use own assembler iirc [22:09:44 CEST] <JEEB> ok so vp9 seemed to work [22:10:29 CEST] <jamrial> JEEB: make the changes ubitux detailed above, nlmeans should compile afterwards [22:10:41 CEST] <JEEB> ok [22:10:45 CEST] <JEEB> yea I did notice that [22:10:58 CEST] <JEEB> I was just trying to double-check that the vp9 part was compiling [22:11:21 CEST] <JEEB> (yup, it did) [22:11:31 CEST] <wbs> JEEB: [22:11:34 CEST] <wbs> oops [22:12:10 CEST] Action: JEEB removes the disablement of nlmeans and prepares to do the change [22:12:47 CEST] <jamrial> uppercase UXTW seems to only be used in this file, but google hints it's valid, so i guess clang's assembler is just picky [22:13:39 CEST] <wbs> jamrial: no, it's not about upper/lower case [22:13:52 CEST] <wbs> it's about x vs w for the regsiter that the uxtw is applied on [22:13:54 CEST] <jamrial> so it was the x1 vs w1? [22:13:56 CEST] <wbs> yes [22:14:08 CEST] <jamrial> alright [22:14:14 CEST] <wbs> uxtw means "do unsigned extension from a 32 bit register to 64 bit register by clearing the upper 32 bits" [22:14:24 CEST] <wbs> but to apply that on a 64 bit register makes no sense [22:17:10 CEST] <wbs> the llvm built-in assembler is generally much more picky than binutils gas, but it's not really missing any significant features any longer, only more strict about sloppy things that gas allows through [22:17:34 CEST] <JEEB> which only leaves GOOG picking some weird revision that has bugs for NDK [22:17:58 CEST] <wbs> uh, what are you implying now? [22:18:04 CEST] <wbs> there was nothing in what you reported that was a bug in llvm [22:18:34 CEST] <JEEB> not regarding this issue [22:19:59 CEST] <JEEB> and that was a roundabout way of me referencing some earlier cases where just NDK clang was broken, not clang in general (either due to source revision being a non-release or due to GOOG's own stuff) [22:21:09 CEST] <wbs> I don't think they do very much extra stuff of their own, they just pick any svn version and backport fixes on top of that with their own usecase in mind. not significantly worse than any normal release in most cases [22:21:42 CEST] <JEEB> alrighty [22:23:12 CEST] <wbs> it's pretty much the same as ffmpeg; latest master _should_ mostly be good, but it can occasionally be bad. public releases may get a bit more external attention, but as long as you run a bunch of tests with your own usecase in mind it should be fine [22:26:03 CEST] Action: durandal_1707 no, i'm not interested in LinkedIn [22:28:48 CEST] <JEEB> ok, I can confirm that the asm file now assembled with the following changes: http://up-cat.net/p/926f28a6 [22:28:58 CEST] <JEEB> which is what I gathered from jamrial's and ubitux's comments [22:33:43 CEST] <durandal_1707> so is it fixed? does lavfi nlmeans denoise anything useful? [22:34:44 CEST] <JEEB> that's not the point [22:34:48 CEST] <JEEB> the build was failing [22:35:03 CEST] <JEEB> so either you disable components or you poke the IRC channel [22:35:58 CEST] <jamrial> JEEB: fix the alignment of the comment in the dup line and ship it [22:36:37 CEST] <JEEB> so I parsed the discussion here correctly? I haven't actually tested it on a device yet [22:37:49 CEST] <wbs> JEEB: anybody with a working build with gas can check that it actually outputs the same disassembly as before, so not much point in testing on a device [22:37:57 CEST] <wbs> (in case it doesn't work, it's not broken by this change anyway) [22:38:14 CEST] <JEEB> ok [22:38:32 CEST] <jamrial> there are no fate tests for nlmean, and if ubitux (the author of the filter) said it's ok, then at most check what wbs mentioned and push [22:39:09 CEST] <durandal_1707> without review? That is against all rules... [22:39:44 CEST] <JEEB> no [22:39:48 CEST] <jamrial> police is on the way [22:39:49 CEST] <JEEB> I will send-email as usual [22:40:33 CEST] <JEEB> anyways, will post it in a moment, need to ask first if my .jp folk need something from .fi [22:48:55 CEST] <JEEB> jamrial: so something like this? https://github.com/jeeb/ffmpeg/commit/a905c5b50c85ec30edd8d651632b0844ea3b5… [22:49:11 CEST] <JEEB> will compare the asm against gcc [22:49:38 CEST] <jamrial> yeah [22:50:26 CEST] <ubitux> 22:38 <jamrial> there are no fate tests for nlmean // not exactly true [22:50:29 CEST] <ubitux> the asm is tested [22:51:08 CEST] <jamrial> ah [22:51:30 CEST] <jamrial> i saw the todo in the c file and assumed it was about the entire filter [22:51:34 CEST] <jamrial> forgot about checkasm [22:57:47 CEST] <JEEB> is objdump or something the best to dump the simd? since vbindiff probably isn't going to cut it ;) [22:59:38 CEST] <wbs> JEEB: objdump -d [22:59:48 CEST] <JEEB> yeh, I just found that option [23:00:53 CEST] <JEEB> ok, is exactly the same [23:01:02 CEST] <JEEB> only the header differs :) [23:01:09 CEST] Action: JEEB does send-email [23:02:29 CEST] <wbs> that's usually the best way to handle that kind of issues anyway; assemble with gas and see what the objdump produces, which might often be the canonical form of typing it (altough I guess someone else already said that) [23:04:35 CEST] <JEEB> anyways, posted on ML [23:07:29 CEST] <JEEB> yea, sounds like it > testing with gas [23:07:39 CEST] <JEEB> (and then objdump -d) [23:08:52 CEST] <sfan5> that makes me wonder, is there nobody doing fate tests on arm64 w/ clang? [23:09:32 CEST] <JEEB> I don't think on FFmpeg, Libav seems to have one [23:09:52 CEST] <JEEB> it does sound like a good idea [23:11:40 CEST] Action: durandal_1707 now getting messages from google employes, someone looked at my github activity [23:13:00 CEST] <atomnuker> poor you, careful with them, they write bad code [23:13:07 CEST] <durandal_1707> lol [23:13:50 CEST] <kierank> durandal_1707: don't join google cult, stay in ffmpeg cult [23:14:55 CEST] <durandal_1707> kierank: someting about end to end streaming shit... [23:15:21 CEST] <kierank> durandal_1707: forward me email [23:15:28 CEST] <durandal_1707> why? [23:16:00 CEST] <kierank> want to see if technical or bullshit [23:16:07 CEST] <kierank> sounds like bullshit [23:53:04 CEST] <BBB> atomnuker: thank you for doing that [00:00:00 CEST] --- Fri Jul 27 2018

1 0

ffmpeg-devel.log.20180725
by burek 26 Jul '18

26 Jul '18

[11:14:17 CEST] <JEEB> kierank: do I remember correctly that DTS > PTS with b-frames is invalid in MPEG-TS (that you just have to add enough difference between DTS and PTS that even with the re-order DTS is always <= PTS) [11:46:50 CEST] <nevcairiel> JEEB: just by sheer logic that would not make sense [11:47:16 CEST] <nevcairiel> decoding timestamp and presentation timestamp, you cant present something before it was decoded [11:52:25 CEST] <JEEB> yes [11:53:14 CEST] <JEEB> i'm mostly trying to double-check [14:05:11 CEST] <January> JEEB: are you sure they don't stand for display timestamp and processing timestamp? [14:06:06 CEST] <JEEB> yes [14:06:15 CEST] <JEEB> I am staring at PTS/DTS straight out of MPEG-TS [15:09:56 CEST] <cone-457> ffmpeg 03Carl Eugen Hoyos 07master:c51e0cd6edbe: lavf/flvdec: Remove an outdated comment. [15:13:52 CEST] <JEEB> wbs: do you remember if this was valid with negative CTS offsets? http://up-cat.net/p/c8f2b5e7 [15:13:58 CEST] <JEEB> at least libavformat doesn't seem to mind [15:14:05 CEST] <JEEB> (the DTS>CTS part) [15:14:25 CEST] <JEEB> or if even with negative CTS offsets you still had to keep DTS<=CTS [15:15:38 CEST] <BradleyS> is there a centralized place tracking deployment of ffmpeg releases by distro? or need to look at each's package repo? [15:16:00 CEST] <JEEB> with the raw values http://up-cat.net/p/899b422d [15:16:24 CEST] <JEEB> BradleyS: yea you'd probably have to check all distros [15:16:57 CEST] <nevcairiel> there is a trac page, but its probably not kept up to date [15:17:14 CEST] <JEEB> yea you'd have to have something dynamically regenerated [15:17:24 CEST] <JEEB> that checks with a cron every midnight or something [16:24:41 CEST] <wingrime> Hi all, I find why bug happends and need some developer agree https://trac.ffmpeg.org/ticket/7052 and comment somehow [17:18:35 CEST] <jdarnley> wingrime: those changes about 0 and EOF seem to have been causing trouble for a few people. The best you can do is produce a patch for it, otherwise just wait for someone who knows what they're doing to fix it. [17:34:46 CEST] <wingrime> jdarnley: nice, Patch indeed good, currenlty I have ugly durty fix, Better solution requires better knowlege in ffmpeg source code [17:35:18 CEST] <wingrime> that I curretly don't have [17:56:08 CEST] <atomnuker> BtbN: I think the bug above should help you nail down the rtmp issue you've had [19:28:57 CEST] <philipl> BtbN: Have you looked at the new nvidia video sdk 8.2 release? [19:51:01 CEST] <philipl> BtbN: Looks like the release notes are accurate. There are new calls to reconfigure a decoder and get decoder status. Everything else is unchanged. [19:59:06 CEST] <wbs> JEEB: that's valid, and that's exactly the whole concept of negative CTS offsets [19:59:14 CEST] <JEEB> yup [19:59:38 CEST] <JEEB> at some point after starting to write a bug report to a 3rd party I started to doubt myself :P [20:00:05 CEST] <JEEB> but I did note that it matches everything I've thought I knew of ISOBMFF and that case [20:02:37 CEST] <JEEB> thank you for verifying that I'm not insane [20:03:55 CEST] <JEEB> sfan5: btw was aarch64 FFmpeg still broken with --disable-avdevice ? or was the only failure with NDK 17b + clang the avdevice thing [20:05:57 CEST] <sfan5> last time i checked it was, no idea if it's the only failure [20:06:18 CEST] <JEEB> ok [20:06:42 CEST] <cone-457> ffmpeg 03Carl Eugen Hoyos 07master:fa35ab80f31e: lavf/isom: Make auxiliary_offsets consistently uint64_t. [20:06:45 CEST] <sfan5> https://0x0.st/sfH7.txt this one [20:06:59 CEST] <JEEB> > nlmeans \o/ [20:07:13 CEST] <JEEB> I didn't even remember that had aarch64 asm [20:23:24 CEST] <atomnuker> thank ubitux [20:30:09 CEST] <durandal_1707> ubitux is on very long vacation [20:31:24 CEST] <jamrial> durandal_1707: he was moving to some place closer to his dayjob, he said a week or so ago [20:41:36 CEST] <cone-457> ffmpeg 03James Almer 07master:81a18f219e2c: avutil/hwcontext_d3d11va: fix type arguments passed to IDXGIAdapter2_GetDesc() [20:43:24 CEST] <cone-457> ffmpeg 03Carl Eugen Hoyos 07master:d01d46ad860c: configure: Force pie for Android. [23:16:26 CEST] <jamrial> jkqxz: i can't realistically use cbs_av1 for a bsf autoinserted by a decoder meant for realtime playback [23:17:31 CEST] <jamrial> i just wrote an av1 packet splitter bsf using it, and compared to a version reading the raw bitstream, the cbs implementation is sixteen times slower [23:19:15 CEST] <jamrial> and this is without using the write/assemble functions, just the read ones, and also limiting the decomposition to only seq, frames/tilegroups and tds [23:20:21 CEST] <jamrial> i'm fairly sure cbs_av1 is a zero copy process, so i'm surprised [23:20:58 CEST] <jamrial> guess all the buffer references created when splitting units are not exactly free [23:27:47 CEST] <atomnuker> what does perf say? [23:28:04 CEST] <atomnuker> I'm still somewhat suspicious of the custom golomb reading function [23:29:09 CEST] <jamrial> haven't tried perf, will do it later [00:00:00 CEST] --- Thu Jul 26 2018

1 0