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

[burek]

[00:16:25 CET] <kerio> i think you can enable interframe compression in ffv1
[00:16:49 CET] <kerio> or hm
[00:17:03 CET] <kerio> maybe you can enable interframe compression in ffvhuff?
[00:17:22 CET] <kerio> ye it was ffv1
[00:17:39 CET] <kerio> ffv1 version 3 has interframe compression
[00:18:04 CET] <Cracki> how can I query the ffv1 version in my ffmpeg?
[00:18:32 CET] <kerio> it defaults to version 1, you can do -level 3
[00:18:36 CET] <Cracki> ah!
[00:18:38 CET] <kerio> see https://trac.ffmpeg.org/wiki/Encode/FFV1
[00:18:54 CET] <kerio> actually, it talks about a gop size for ffv1 version 1 too
[00:20:37 CET] <Cracki> still a lot of bits... 14 Mbit/s
[00:21:17 CET] <Cracki> nothing in the codec description says it can do inter prediction
[00:21:27 CET] <Cracki> only the coding tables might adapt
[00:26:51 CET] <Cracki> ffv1 is intra-only
[00:27:04 CET] <Cracki> the only effect a gop size > 1 has is the coding tables
[00:27:06 CET] <Cracki> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2012-April/122967.html
[00:27:46 CET] <Cracki> it's definitely not designed for inter prediction
[02:09:38 CET] <FishPencil> Is there anything out there that uses FFmpeg to create an image of several thumbnails? I know the tile filter works, but this doesn't support splitting the stream into n sections
[02:10:00 CET] <TAFB> can ffmpeg receive a pushed rtmp stream? i.e. I have a camera that can ONLY push out to youtube "pushStream uri=rtmp://a.rtmp.youtube.com/live2/ localstreamname=s0 targetStreamName=xxxx-xxxx-xxxx-xxxx forceTcp=true" could I somehow set up ffmpeg to receive that stream? I've changed the DNS in my router to point a.rtmp.youtube.com back to my computer, so no problem there, just not sure how to
[02:10:00 CET] <TAFB> make ffmpeg listen
[02:21:44 CET] <DHE> TAFB: https://ffmpeg.org/ffmpeg-all.html#rtmp  in theory, yes
[02:37:04 CET] <Steve132> Hello!  I'm having trouble navigating the right way to do something
[02:38:29 CET] <Steve132> I have a very limited bandwidth at a remote location where I'd like to display a certain web stream on 5 concurrent clients
[02:38:39 CET] <Steve132> so my thought is that I can use ffmpeg to or vlc
[02:39:08 CET] <Steve132> to download the stream over the remote link and re-broadcast it over the lan using multicast
[02:39:25 CET] <Steve132> I've tried using ffmpeg and vlc and I haven't been able to figure out how to make it work with either one
[02:39:32 CET] <Steve132> Any ideas?
[02:42:13 CET] <DHE> can you play your video with ffplay?
[02:42:19 CET] <DHE> from the remote site
[02:42:24 CET] <DHE> first step is to get it into ffmpeg
[02:49:29 CET] <Steve132> Yes I can
[02:49:31 CET] <Steve132> I'll verify that now
[02:50:01 CET] <Steve132> Yes.
[02:50:40 CET] <DHE> okay. now we have to decide the output format. multicast works best with (near) constant bitrates. I'm a fan of mpegts, but it will likely require H264 video and AAC audio. does the source meet those critera?
[02:51:03 CET] <DHE> or do you have a specific target in mind already
[02:51:18 CET] <Steve132> Yes
[02:51:24 CET] <Steve132> it even says it's already using mpegts
[02:51:33 CET] <DHE> oh, cool...
[02:51:41 CET] <Steve132> If I could avoid transcoding that would obviously be the best.
[02:52:08 CET] <DHE> okay... so assuming the target bitrate is 9.5 megabits total (to pick a number out of the air) I would go with something like:
[02:52:19 CET] <Steve132> Input #0, mpegts, from '<url>':KB sq=    0B f=0/0      Duration: N/A, start: 27450.249000, bitrate: N/A   Program 1      Stream #0:0[0x100]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 153 kb/s     Stream #0:1[0x101]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p, 1280x720, 60 tbr, 90k tbn, 2k tbc     Stream #0:2[0x102]: Data: timed_id3 (ID3  / 0x20334449)
[02:52:40 CET] <DHE> ffmpeg -i [input] -c copy -f mpegts -muxrate 9.5M -bitrate 9.5M udp://239.255.0.1:12345
[02:52:53 CET] <DHE> when in doubt, increase the bitrate and muxrate. better to be too high than even a bit too low
[02:53:49 CET] <Steve132> It says "unrecognized option bitrate"
[02:53:58 CET] <DHE> oh dear, you have an old version...
[02:54:14 CET] <Steve132> I can update hold on
[02:54:22 CET] <Steve132> I'm on mint
[02:54:27 CET] <DHE> I really would recommend setting a bitrate or you may be prone to minor packet loss on the network, and multicast like this has basically zero tolerance to loss
[02:56:44 CET] <Steve132> Is there a recommended ppa for mint or ubuntu that's reasonably up to date?
[02:56:53 CET] <DHE> I wouldn't know
[02:57:04 CET] <DHE> for experiments, go ahead and omit the bitrate
[02:57:45 CET] <Steve132> Okay, well I'm updating anyway
[02:57:46 CET] <DHE> you can play videos back with vlc opening the same network path
[02:58:04 CET] <Steve132> give me 2 seconds
[02:58:18 CET] <Steve132> okay updated
[02:58:40 CET] <Steve132> "av_interleaved_write_frame(): Cannot allocate memory Error writing trailer of udp://239.255.0.1:12345: Cannot allocate memory frame=  138 fps=0.0 q=-1.0 Lsize=    5254kB time=00:00:04.54 bitrate=9464.3kbits/s speed=1.32e+03x     video:1148kB audio:91kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 323.914032% Conversion failed!"
[02:59:27 CET] <DHE> high speed. so the source is probably mpeg-dash or the like. try -re in front of the input option
[03:00:51 CET] <Steve132> okay
[03:01:07 CET] <Steve132> so I'm running vlc udp://239.255.0.1:12345
[03:01:41 CET] <Steve132> Nothing is playing, vlc reports 'error, cannot pre-fill buffer'
[03:02:21 CET] <DHE> so ffmpeg got working?
[03:02:34 CET] <Steve132> Yep, it's running and saying that it's outputting frames
[03:02:45 CET] <Steve132> which I assume means it's casting to the udp multicast address
[03:03:15 CET] <Steve132> So how do I play it?
[03:04:10 CET] <DHE> odd... that works for me...
[03:04:23 CET] <Steve132> Maybe my vlc is out of date?
[03:04:25 CET] <Steve132> Can I try ffplay?
[03:04:46 CET] <DHE> I guess?
[03:05:06 CET] <DHE> I apologize, it's late here. I'm checking if I'm missing anything...
[03:05:12 CET] <Steve132> No problem
[03:05:29 CET] <Steve132> I tried ffplay -i udp://239.255.0.1:12345
[03:05:32 CET] <Steve132> and it says
[03:05:34 CET] <Steve132> "[AVBSFContext @ 0x7f690c5457e0] Invalid NAL unit 0, skipping. [h264 @ 0x7f690c549a60] non-existing PPS 0 referenced [h264 @ 0x7f690c549a60] decode_slice_header error [h264 @ 0x7f690c549a60] no frame!"
[03:06:22 CET] <DHE> no buffer filling means I would probably check for obvious networking issues. everybody is on the same layer 2 network, no firewalls blocking traffic. tcpdump or wireshark can match with rule "host 239.255.0.1"
[03:07:10 CET] <DHE> a few errors on startup is normal because the stream is joined partially in progress and the first frame seen is unlikely to be a keyframe
[03:09:33 CET] <DHE> I checked my notes, there is an output option that should be added -pkt_size 1316 which could also be added to the UDP URL like udp://239.255.0.1:12345?pkt_size=1316
[03:11:48 CET] <Steve132> okay
[03:11:53 CET] <Steve132> I'm testing this on localhost
[03:12:02 CET] <Steve132> so the network should be the same
[03:12:09 CET] <Steve132> how can I check for a firewall?
[03:13:10 CET] <DHE> well, on linux I usually use tcpdump and look for the UDP packets on each side. make sure they'are arriving first, then check the firewall rules specifically
[03:13:35 CET] <DHE> depending on the network, you may only receive the feed while trying to play it.
[03:15:35 CET] <Steve132> 22:15:04.494254 IP 192.168.1.121.52577 > 239.255.0.1.12345: UDP, length 1316 22:15:04.495350 IP 192.168.1.121.52577 > 239.255.0.1.12345: UDP, length 1316 22:15:04.496457 IP 192.168.1.121.52577 > 239.255.0.1.12345: UDP, length 1316 22:15:04.497549 IP 192.168.1.121.52577 > 239.255.0.1.12345: UDP, length 1316 22:15:04.498674 IP 192.168.1.121.52577 > 239.255.0.1.12345: UDP, length 1316 22:15:04.499791 IP 192.168.1.121.52577 > 239.255.0
[03:15:44 CET] <Steve132> so the packets are pushing to the multicast address
[03:17:08 CET] <Steve132> Can I use RTP or RTSP?
[03:17:35 CET] <DHE> rtp can work in multicast I think. but ffmpeg itself can't do mass distribution..
[03:17:54 CET] <DHE> it can feed something else like nginx-rtmp to do that job...
[03:19:10 CET] <Cracki> rtp/rtsp/rtcp is a set of protocols/layers that work in concert
[03:20:03 CET] <Cracki> rtsp/rtcp control the flow/congestion and perform logical operations such as stream start, stop, rewind/seeking, ...
[03:20:27 CET] <Cracki> rtp does work in multicast. that's what it's made for.
[03:20:38 CET] <Cracki> vlc can blast to multicast addresses
[03:23:03 CET] <DHE> mpegts is literally what's broadcast over the air for digital TV channels, so it lends itself to easy network multicast conversion as well. also related to why it's my go-to.
[03:28:51 CET] <Cracki> also, vlc is literally made for distributing video in a lan
[03:29:17 CET] <Cracki> it can receive (and transcode) and serve streams
[03:33:01 CET] <Steve132> Cracki: I've tried using vlc but no luck
[03:33:05 CET] <Steve132> any help?
[03:33:10 CET] <Cracki> yes, #vlc or ##vlc
[03:59:44 CET] <blap> ASCII a stupid question, get a stupid ANSI
[04:02:27 CET] <FishPencil> Is there a faster way to -vf fps like how -ss does the fast seak?
[04:13:34 CET] <malkauns> omg there'san ffmpeg channel?? :)
[04:14:30 CET] <malkauns> oh well here goes, how do i convert from hevc 2160p HDR to x264 and preserve HDR?
[04:32:16 CET] <blap> stick around malkauns - if someone knows they will answer
[04:39:58 CET] <malkauns> ooooo k
[07:19:43 CET] <brotherBox> hi guys, i have a weird video file that appears corrrupted in players like mpv and vlc but playst jus fine in ffplay; asking ffmpeg to copy video and audio stream to a different file (which is often touted as a general fix for video files) only copies over the problem to the new file. what is going on here and is there any way to fix this file?
[08:53:18 CET] <jason___> hello
[08:54:13 CET] <jason___> in ffmpeg, is there a way to encode two sequences of images into a side-by-side video? thanks.
[09:07:52 CET] <blap> i think so
[09:09:36 CET] <jason___> how to?
[09:09:55 CET] <Nacht> Easiest I recon is to create 2 seperate video's from the image sequences. Then merget them using this: https://unix.stackexchange.com/questions/233832/merge-two-video-clips-into-one-placing-them-next-to-each-other
[09:10:04 CET] <Nacht> -t
[09:11:12 CET] <jason___> does the overlay filter support two inputs of image sequences
[09:11:18 CET] <jason___> @Nacht thanks, that's certainly a way to do that
[09:13:57 CET] <brotherBox> hi guys, i have a weird video file that appears corrrupted in players like mpv and vlc but playst jus fine in ffplay; asking ffmpeg to copy video and audio stream to a different file (which is often touted as a general fix for video files) only copies over the problem to the new file. what is going on here and is there any way to fix this file?
[09:21:45 CET] <Nacht> brotherBox: Have you tried transcoding the video ?
[09:37:32 CET] <brotherBox> Nacht: im supplying -c libx264 for example and its still corrupted
[12:00:59 CET] <Fyr> guys, I have a corrupt MP4 file. players can play it easily, however, FFMPEG cannot mux the file into another container. is there a solution for this?
[12:02:43 CET] <pomaranc> Fyr: well, you can play the file and screen capture it :D
[12:09:21 CET] <CoReX> Fyr mux it with a diffrent application maybe ?
[12:29:33 CET] <Fyr> CoReX, what application do you recommend?
[12:36:44 CET] <Mavrik> try VLC?
[12:52:28 CET] <CoReX> Fyr if your on windows just use mkvmerge and see if it plays fine then
[13:06:22 CET] <Fyr> thanks
[13:06:39 CET] <Fyr> mkvtoolnix works like a charm.
[14:12:22 CET] <yonilevy> hi, question: i'm using `avformat_open_input` to connect to an RTSP stream. the thing is, i the sockets used in the RTSP game to be bound to specific local host (so they'll be routed through a specific network interface). is there a way to do that without changing the code?
[14:12:24 CET] <diqidoq> How can I choose an output driver with ffplay (like mplayer -ao jack) ?
[14:28:03 CET] <durandal_1707> diqidoq: you cant, use sdl env variables
[15:34:57 CET] <diqidoq> durandal_1707: thank you!
[16:12:09 CET] <kerio> is the timebase a property of the codec?
[16:12:14 CET] <kerio> or is it a property of the muxer?
[16:12:30 CET] <JEEB> it's a property of the stream, which can either come from the headers of the stream or from the container
[16:12:48 CET] <kerio> my 1000k tbr gets changed to 9 if i reencode the video, but it stays at 1000k if i use -c:v copy
[16:13:33 CET] <JEEB> decoders, filter graphs and maybe even encoders can change the time base
[16:13:49 CET] <JEEB> so it's a change that happens during the chain of events that doesn't happen during -c copy
[16:14:04 CET] <kerio> how do i make it not do that
[16:14:38 CET] <JEEB> most simple is most likely to just try and force the time base at the output muxer
[16:15:02 CET] <JEEB> -time_base "1:1000" for example
[16:15:14 CET] <JEEB> (and you probably want to utilize the limiters)
[16:15:18 CET] <JEEB> if you want to set it per-stream
[16:15:51 CET] <kerio> how can i check that the timestamps stay the same?
[16:15:56 CET] <kerio> can i assume that?
[16:16:35 CET] <JEEB> if you really want to copy timestamps then I think you also need other values :P
[16:16:55 CET] <kerio> i don't understand if copyts is per-stream or not
[16:16:59 CET] <JEEB> it isn't
[16:17:19 CET] <JEEB> also do note that since the decoder etc can change the time base accordingly I am not sure if copyts means 100% timestamp copying
[16:20:17 CET] <kerio> yay the timestamps stay the same
[16:20:51 CET] <kerio> (i checked by saving the same stream twice, once encoded and once copied, and extracting the timestamps with ffprobe
[16:20:55 CET] <kerio> )
[17:07:40 CET] <watom> hey. can i in some way use ffmpeg to recodify in streaming a web radio to another machine?
[17:07:54 CET] <watom> i have a radio that is too high bitrate and i need to listen to it on a mobile limited data plan
[17:07:57 CET] <watom> maybe i can ffmpeg+ssh it?
[17:08:26 CET] <malkauns> how do i convert from hevc 2160p HDR to x264 and preserve HDR?
[17:08:28 CET] <Nacht> watom: audio isn't that intensive
[17:09:37 CET] <JEEB> malkauns: you have to keep the mastering data sei and encode in 10bit
[17:10:40 CET] <malkauns> ok, any idea how? in the form of an ffmpeg command? :)
[17:11:08 CET] <watom> Nacht 192 kbit/s is 24 kB/s wich is 1,5 MB/min...
[17:11:10 CET] <JEEB> not sure if ffmpeg.c can do that currently. the decoder does export the contents of the SEI as metadata
[17:11:18 CET] <watom> it's kinda intensive if you have few data each month
[17:11:46 CET] <watom> i can opus to 64 tbh
[17:11:59 CET] <watom> but i need a way to forward this while decoding/encoding on the fly
[17:12:08 CET] <Nacht> watom: I meant, yeah you can transcode it, it's not that intensive to do
[17:12:15 CET] <watom> yep
[17:12:19 CET] <watom> but i don't know how to do that
[17:12:42 CET] <kepstin> heh, with opus 1.2 you could probably get by with 48kbit/s for internet radio
[17:12:50 CET] <watom> nice
[17:12:53 CET] <watom> i need a line for that...
[17:13:04 CET] <watom> combined with ssh i guess
[17:13:30 CET] <kepstin> basically, you need to decide how you want to get the audio from your server to the player on your mobile device
[17:13:44 CET] <kepstin> what player are you gonna be using, what protocols can it read?
[17:14:00 CET] <watom> vlc
[17:14:23 CET] <Nacht> what kind of source  ?
[17:14:30 CET] <watom> not sure about that
[17:14:32 CET] <watom> is a web radio page
[17:14:37 CET] <watom> i investigate wait a moment
[17:14:38 CET] <kepstin> I assume the source is some kind of http or icecast stream
[17:14:44 CET] <Nacht> Prolly icecast
[17:14:47 CET] <kepstin> ffmpeg shouldn't have an issue reading that
[17:15:05 CET] <kepstin> so the problem is getting the transcoded audio out of ffmpeg to the mobile device
[17:15:14 CET] <Nacht> Nope. I made my own small systemd service who takes icecast and transcodes it to multibitrate hls
[17:15:32 CET] <kepstin> which is sometimes a bit tricky, since ffmpeg isn't a streaming server in itself
[17:15:48 CET] <kepstin> if vlc can do opus in mpegts, then yeah, hls is an option
[17:16:25 CET] <watom> maybe this http://b2everyrai-lh.akamaihd.net/i/radio7_1@446147/segment150946648_200_a-p.ts?sd=10&rebase=on
[17:16:34 CET] <watom> i see lot of that segments in the network of the dev tools
[17:16:51 CET] <watom> maybe .ts?
[17:16:59 CET] <kepstin> a segment with ts? so yeah, that source is probably hls, you'd need to get the playlist (m3u8 probably) link
[17:17:12 CET] <watom> i'm no good
[17:17:14 CET] <Nacht> https://pastebin.com/vQ5feytk
[17:17:15 CET] <watom> http://www.radiorai.rai.it/dl/portaleRadio/popup/player_radio.html
[17:17:16 CET] <Nacht> That's what I made
[17:17:19 CET] <watom> that's the radio page
[17:18:05 CET] <Nacht> its already HLS
[17:18:14 CET] <watom> i get a 170 kB/s segment
[17:18:24 CET] <Nacht> BANDWIDTH=125000
[17:18:26 CET] <watom> i need to take this to ffmpeg encode again in opus and stream to a remote vlc
[17:18:51 CET] <kepstin> hmm, so the source is hls, but the master playlist files take an auth key, that's kind of annoying
[17:18:56 CET] <Nacht> http://b2everyrai-lh.akamaihd.net/i/radio1es_1@389755/index_200_a-p.m3u8 is your source
[17:19:05 CET] <watom> Nacht where i get those links
[17:19:14 CET] <watom> you see there are multiple radio stations there
[17:19:19 CET] <kepstin> oh, huh, works without the auth key
[17:19:31 CET] <Nacht> Aye. you use your developer window for that under tab network
[17:19:32 CET] <kepstin> watom: open web inspector in browser, look for the 'm3u8' file it fetches
[17:19:35 CET] <Nacht> Press F12 in your browser
[17:19:45 CET] <watom> nice
[17:19:53 CET] <watom> i get give this to ffmpeg?
[17:20:00 CET] <watom> can*
[17:20:11 CET] <Nacht> Aye
[17:20:24 CET] <watom> and how i can output this to a stream that vlc can read?
[17:20:33 CET] <Nacht> Well that's the problem. You need to host it
[17:20:43 CET] <watom> ffmpeg is not enough?
[17:21:04 CET] <kepstin> ffmpeg is not itself a media server (or at least not a good one)
[17:21:06 CET] <Nacht> ffmpeg can turn it into everything you want it to be. But getting it to your mobile is the tricky part
[17:21:27 CET] <Nacht> I assume you don't have a webserver ?
[17:21:37 CET] <watom> i have a 24/7 raspberrypi
[17:21:43 CET] <watom> at home
[17:21:47 CET] <watom> with linux
[17:22:03 CET] <kepstin> sure, but how is your phone gonna connect to that?
[17:22:12 CET] <watom> i don't know.
[17:22:16 CET] <Nacht> I assume you dont have a static IP
[17:22:24 CET] <watom> i already have a way to reach it
[17:22:27 CET] <watom> dynamic dns
[17:22:30 CET] <watom> i use ssh already
[17:23:08 CET] <Nacht> In that case if you host a webserver there, and then transcode to HLS on that (raspbian has avconv which might be able to do that)
[17:23:12 CET] <Nacht> then direct port 80 to your RPI
[17:23:22 CET] <Nacht> you could access it from the outside
[17:23:37 CET] <watom> transcoding to hls will give me a file?
[17:23:41 CET] <kepstin> might want to use a different port externally, but yeah, that's probably the simplest way
[17:23:45 CET] <watom> that i should link in the /var/www?
[17:23:50 CET] <Nacht> Correct
[17:23:59 CET] <kepstin> transcoding to hls will give a directory of multiple constantly rewritten files that you should host with an http server
[17:24:01 CET] <watom> sounds ok
[17:24:11 CET] <watom> and i just point the vlc to that directory?
[17:24:17 CET] <Nacht> ffmpeg will create 2 things when it makes an HLS. It will make a manifest (.m3u8) and segements (.ts)
[17:24:21 CET] <watom> or there is a main file?
[17:24:23 CET] <watom> i see
[17:24:28 CET] <watom> so i will point the vlc to m3u8
[17:24:32 CET] <Nacht> Correct
[17:24:35 CET] <watom> i need a line to create that hls thing
[17:24:39 CET] <watom> from my m3u8 radio
[17:24:59 CET] <Nacht> Take a look at my script, it basicly all you need
[17:24:59 CET] <Nacht>  https://pastebin.com/vQ5feytk
[17:25:14 CET] <kepstin> the command is basically just this: ffmpeg -i 'http://b2everyrai-lh.akamaihd.net/i/radio1es_1@389755/master.m3u8' -c:a libopus -b:a 48K -f hls -hls_flags delete_segments test.m3u8 yeah
[17:25:17 CET] <Nacht> if you have systemd I suggest using that
[17:25:21 CET] <Nacht> so you can daemonise it
[17:25:25 CET] <kepstin> recent vlc should play that.
[17:25:29 CET] <watom> ok guys
[17:25:36 CET] <watom> let me try i need some times
[17:26:11 CET] <Nacht> https://pastebin.com/5CJNk9kw systemd service
[17:26:47 CET] <watom> meanwhile i tried if the radio m3u8 stream fine on the device
[17:26:48 CET] <watom> and it does
[17:26:56 CET] <watom> now i just get a http server up and try that ffmpeg line
[17:26:58 CET] <furq> opus in hls?
[17:27:01 CET] <watom> to the www path
[17:27:08 CET] <watom> furq is that a bad idea?
[17:27:13 CET] <watom> i just need low bitratio
[17:27:18 CET] <furq> it is if you want people to be able to play it
[17:27:24 CET] <watom> it's personal use
[17:27:28 CET] <Nacht> afaik hls doesnt support opus
[17:27:36 CET] <Nacht> as in apple doesnt support opus
[17:27:37 CET] <watom> what about aac
[17:27:38 CET] <furq> mpegts supports opus, so it'll mux and probably play back in mpv or something
[17:27:41 CET] <Nacht> aac and mp3
[17:27:43 CET] <watom> 64 kbit/s aac
[17:27:46 CET] <furq> but if you want it to work in browsers then you need to use aac
[17:27:46 CET] <watom> should be fine too
[17:27:55 CET] <kepstin> ffmpeg can put opus in ts, mpv can play opus in hls.
[17:27:59 CET] <furq> right
[17:28:04 CET] <kepstin> dunno about vlc, maybe?
[17:28:04 CET] <furq> if it's for personal use then it should work
[17:28:04 CET] <Nacht> TIL
[17:28:05 CET] <watom> i try opus.
[17:28:08 CET] <watom> if doesn't work i try aac
[17:28:37 CET] <watom> what about the output on /tmp (RAM)?
[17:28:44 CET] <watom> so i don't write the sd a lot
[17:28:46 CET] <furq> sure
[17:28:56 CET] <watom> but will ffmpeg fill it infinite?
[17:29:00 CET] <watom> or old files will auto delete
[17:29:13 CET] <kepstin> watom: if you use -hls_flags delete_segments, ffmpeg will clean up the old files
[17:29:18 CET] <watom> cool
[17:29:20 CET] <Nacht> -hls_flags delete_segments
[17:29:33 CET] <watom> ok. gonna work on it now
[17:29:37 CET] <furq> isn't that enabled by default
[17:29:52 CET] <furq> no harm setting it anyway
[17:29:54 CET] <kepstin> i dunno. I can never remember, and the help doesn't say
[17:30:16 CET] <furq> hls_list_size is set by default anyway so that's fine
[17:30:35 CET] <kepstin> with these streams, you might want to set "-hls_time 10" as well, since the original segment length is 10. could cause less buffering weirdness then.
[17:31:04 CET] <kepstin> (otherwise you'd have to increase the -hls_list_size)
[17:31:13 CET] <furq> you might just want to set up icecast on the pi or something
[17:31:27 CET] <furq> that seems a bit less hacky
[17:31:44 CET] <watom> to be honest that sounds easy and clean...
[17:31:47 CET] <kepstin> that's probably not a bad idea. certainly less overhead than hls, and recent icecast can do vorbis, opus, mp3, and aac i think
[17:31:48 CET] <watom> i feel lice icecast is more complex
[17:31:57 CET] <watom> like*
[17:32:10 CET] <watom> i mean it's kinda easy to transcode ffmpeg to a path and put that path in the web server
[17:32:20 CET] <watom> not sure about icecast. but i remember a time when i tried it and was kinda hard to use
[17:32:35 CET] <Nacht> You could do an icecast indeed
[17:32:53 CET] <furq> it's pretty simple to set up and it'll work in any remote client
[17:32:58 CET] <furq> but yeah if this works then shrug
[17:33:03 CET] <Nacht> But you'd still need ingest
[17:33:10 CET] <furq> you can use ffmpeg for ingest
[17:33:16 CET] <Nacht> Doubt you can relay a non-icecast mount
[17:33:19 CET] <furq> icecast would introduce much less latency as well
[17:33:31 CET] <furq> if that matters
[17:33:53 CET] <watom> how much latency will be there now?
[17:33:55 CET] <Nacht> RAI might even have icecast streams, but they might still be 128k
[17:33:58 CET] <watom> more than a second?
[17:34:04 CET] <furq> very much more than a second, yeah
[17:34:14 CET] <watom> if is few seconds i don't really care
[17:34:16 CET] <furq> hls always buffers at least two full segments, so ~20 seconds
[17:34:23 CET] <watom> is not communication is just listening...
[17:34:27 CET] <furq> or 40 seconds since you're going hls to hls
[17:34:30 CET] <watom> but if i can save more bandwith i'm interested
[17:34:50 CET] <furq> icecast would use less bandwidth but idk if it'd be a noticeable amount
[17:35:09 CET] <furq> only one http request instead of one per segment
[17:35:26 CET] <watom> how much big is a segment?
[17:35:42 CET] <furq> apparently 10 seconds
[17:35:58 CET] <watom> so if i fail to get one of em i lose 10 secs?
[17:36:00 CET] <watom> that sounds bad
[17:36:03 CET] <furq> it'll keep retrying
[17:36:13 CET] <watom> so doesn't skip
[17:36:15 CET] <watom> ok
[17:36:55 CET] <Nacht> They do have icecast btw, 96mp3 at least
[17:36:55 CET] <Nacht> http://icestreaming.rai.it/1.mp3
[17:37:08 CET] <furq> oh neat
[17:37:19 CET] <furq> well yeah an icecast relay would be a lot simpler then
[17:37:25 CET] <furq> if you need 48k
[17:37:34 CET] <watom> Nacht nice discovery!
[17:37:37 CET] <watom> where is this?
[17:37:52 CET] <Nacht> https://tunein.com/radio/RAI-Radio-1-934-s25212/
[17:38:05 CET] <watom> tunein? is that official?
[17:38:20 CET] <Nacht> The thing is, most older webradio's can't play HLS
[17:38:27 CET] <Nacht> So stations still offer Icecast
[17:38:45 CET] <furq> well the actual feed is on rai.it
[17:38:48 CET] <furq> so i'm guessing it is official
[17:38:48 CET] <Nacht> And tunein.com (and a few others sites) are used by these radio's to fetch their URL's
[17:38:53 CET] <Nacht> which are maintained by the stations
[17:38:58 CET] <furq> tunein is just an aggregator iirc
[17:39:02 CET] <watom> yeah it's on the rai domain
[17:39:03 CET] <watom> http://icestreaming.rai.it/2.mp3
[17:39:06 CET] <watom> furq yeah
[17:39:23 CET] <Nacht> Yeah, these will be maintained. As listeners are all stations care about
[17:39:31 CET] <Nacht> and dead links are no listeners
[17:40:08 CET] <Nacht> http://icestreaming.rai.it/status.xsl
[17:40:16 CET] <Nacht> tut tut Rai, bad security
[17:40:37 CET] <watom> nice link
[17:40:48 CET] <furq> lol
[17:40:56 CET] <furq> it does need a login to do any admin stuff
[17:41:06 CET] <Nacht> True, but you can see the listeners
[17:41:26 CET] <furq> just be glad they offer icecast at all
[17:41:30 CET] <furq> i'm pretty sure the bbc doesn't any more
[17:41:45 CET] <watom> how many listeners or IPs?
[17:41:59 CET] <Nacht> I know BBC uses Unified for their radiostreams now
[17:42:24 CET] <Nacht> not too sure if they stopped offering Icecast. But they're usually ahead with these things, so you are prolly correct
[17:43:09 CET] <watom> what is the modern way to do that?
[17:43:26 CET] <Nacht> HLS
[17:43:40 CET] <watom> but why we use hls
[17:43:48 CET] <watom> if icecast have less latency
[17:43:49 CET] <Nacht> Cause its cacheable
[17:44:05 CET] <watom> and we want to cache to?
[17:44:07 CET] <furq> yeah hls is easier if you're using a cdn
[17:44:09 CET] <Nacht> So less traffic on your origins, and you can let Akamai do its stuff
[17:44:15 CET] <furq> because you can have the cdn cache the fragments
[17:44:23 CET] <watom> i see
[17:44:27 CET] <furq> they're just regular (short-lived) files
[17:44:32 CET] <furq> over regular http
[17:44:40 CET] <watom> or https i guess
[17:44:52 CET] <furq> sure
[17:44:57 CET] <Nacht> nways, im off.
[17:45:04 CET] <furq> also i guess the bbc does still have some shoutcast streams
[17:45:09 CET] <furq> they do a good job of not advertising them though
[17:45:11 CET] <watom> thank you. expecially for thate icecast page :)
[17:45:19 CET] <watom> i can use it meanwhile i get my thing setup
[17:46:38 CET] <watom> thanks for the hints. i had no idea now i know 2 ways to do this guys
[17:46:41 CET] <watom> o/
[17:47:01 CET] <watom> and i will try 48 kbit/s opus that sounds interesting
[17:47:12 CET] <furq> if it's speech then you might be able to go even lower
[17:47:32 CET] <watom> it's fine. they stream music between speechs
[17:47:35 CET] <sfan5> 16 or 32 should be fine for speech, 96 is okay for music
[17:47:44 CET] <furq> yeah 48 should still sound ok for music
[17:47:51 CET] <watom> 96 is for high quality sfan5
[17:47:53 CET] <furq> not archival quality obviously, but good enough
[17:47:59 CET] <watom> i will hear on headphones
[17:48:04 CET] <watom> and they kinda sucks so
[17:48:17 CET] <sfan5> pretty sure the hydrogenaudio wiki says 128k opus is "high quality"
[17:48:21 CET] <furq> it's cool that 128kbps is finally "cd quality" now
[17:48:21 CET] <sfan5> but it's all subjective
[17:48:27 CET] <furq> even if it took 20 years after they first announced that
[17:48:29 CET] <watom> 128 is transparent
[17:48:37 CET] <watom> high quality is a different thing
[17:48:45 CET] <watom> 128 k should sound like raw
[17:48:47 CET] <furq> 128 should be transparent, yeah
[17:49:04 CET] <watom> 64 kbit/s on headphones is like the same tbh
[17:49:17 CET] <watom> never tried 48
[17:49:32 CET] <watom> but i mean i can go to 64...
[19:59:31 CET] <cryptodechange> Currently encoding some 80's movie blu rays, would I be better sticking with preset grain?
[19:59:59 CET] <klaxa> encode a short sample and compare
[20:00:13 CET] <cryptodechange> Not sure what deadzone=6,6 vs. 21,11 and ip/pb ratio = 1.1 vs. 1.4
[20:00:23 CET] <cryptodechange> Yeah
[20:00:32 CET] <cryptodechange> I've unset psy_trellis for most of my encodes
[20:07:06 CET] <furq> cryptodechange: lower ipratio = lower quantiser (higher quality) for I frames, lower pbratio = higher quantiser for B frames
[20:07:11 CET] <furq> no, that's not a typo
[20:09:22 CET] <furq> also deadzone doesn't do anything if trellis is enabled, and iirc trellis takes precedence if it's set, which it is for all presets above medium
[20:10:00 CET] <furq> with that said i just use film for anything that was shot on film and it looks fine
[20:20:20 CET] <alexpigment> furq: out of curiosity, does the film preset do anything to specifically help film (e.g. preserve grain), or is it just a "throw everything at it to preserve quality" setting?
[20:21:36 CET] <alexpigment> i never specify a tune preset, although perhaps i should
[20:27:09 CET] <furq> it biases towards preserving fine detail
[20:27:19 CET] <furq> so it preserves grain a bit, but not as much as -tune grain
[20:28:55 CET] <alexpigment> hmmm. maybe i should start using that ;)
[20:29:30 CET] <alexpigment> i don't know why i don't specify -tune . i just never could figure out the pros and cons when it was introduced
[21:18:29 CET] <cryptodechange> qcomp is a bit higher in grain than the default, googling it comes up with compression. Does keeping it lower (the default), yield higher quality?
[22:15:33 CET] <pgorley> can i hardware encode with mediacodec in ffmpeg or is just for decoding? is encoding support planned?
[22:16:04 CET] <JEEB> decoder was made but I've not heard of anyone being interested of encoding
[22:16:25 CET] <pgorley> JEEB: oh, ok
[23:28:23 CET] <fella> i think there's an option to libx264 which makes it write out atoms every n-seconds or so, but I can't remember what it is called or where it is documented?
[23:40:38 CET] <fella> think i found it: http://ffmpeg.org/ffmpeg-all.html#toc-mov_002c-mp4_002c-ismv
[23:41:01 CET] <fella> ^^ -movflags fraq_keyframe
[23:41:15 CET] <JEEB> libx264 has nothing to do with ISOBMFF structures
[23:41:32 CET] <JEEB> it has a mode where it inserts the parameter sets at each IRAP
[23:41:48 CET] <JEEB> but that has nothing to do with, you know, ISOBMFF
[23:42:00 CET] <JEEB> meanwhile yes, frag_keyframe enables the default way of fragmenting ISOBMFF
[23:42:33 CET] <JEEB> so that you have no global index but instead get small fragments in the file
[23:42:59 CET] <fella> well, what i'm looking for is a way to keep my stream encoding playable even if that original stream fails
[23:43:38 CET] <JEEB> I would recommend just using a container that doesn't have an index for that step
[23:43:41 CET] <JEEB> like mpeg-ts
[23:43:41 CET] <JEEB> or NUT
[23:43:43 CET] <JEEB> or matroska
[23:43:59 CET] <JEEB> then you can remultiplex that to mp4 or whatever afterwards
[23:44:18 CET] <fella> the original stream is mpeg-ts i think but i want to encode it on the fly to mp4
[23:44:35 CET] <JEEB> then fragmented ISOBMFF is the least bad alternative I guess :P
[23:55:19 CET] <fella> Error setting option movflags to value fraq_keyframe
[23:56:19 CET] <JEEB> G
[23:56:21 CET] <JEEB> not Q
[23:56:27 CET] <JEEB> FRAGments
[23:57:36 CET] <fella> lol - i already wondered about that - must be the font ;)
[00:00:00 CET] --- Wed Nov  1 2017