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

[burek]

[00:57:14 CEST] <poisond> hi :) Are the available codec parameters for nvenc_h265 documented somewhere?
[00:58:01 CEST] <poisond> are they the same as for x265?
[01:07:17 CEST] <BtbN> poisond, there is some command to list the options.
[01:09:25 CEST] <BtbN> poisond, ffmpeg -h full shoult list them, i forgot what the command was to display only the help for one codec.
[01:09:28 CEST] <BtbN> *d
[01:12:06 CEST] <poisond> I'm not seeing it :/
[01:17:28 CEST] <BtbN> Does it list nvenc in the -encoders output?
[01:18:25 CEST] <poisond> yeah, nvenc and nvenc_h265. But I'm looking for a list of supported options of those encoders. The ones from libx265 don't work
[01:18:45 CEST] <poisond> like -profile
[01:18:48 CEST] <BtbN> Yes, -h full should have it
[01:19:55 CEST] <poisond> aaaaah, sorry. already past midnight and I should read more carefully ^^
[01:20:40 CEST] <BtbN> They are roughly inspired by the x264 options, but not the same.
[01:23:19 CEST] <poisond> wow, transcoding at 80 FPS, definately better than ~7FPS :)
[01:23:40 CEST] <BtbN> Don't expect too much from the quality though.
[01:24:02 CEST] <poisond> :(
[01:24:51 CEST] <BtbN> Even x265 is currently still beaten by x264, depending on the settings.
[01:25:14 CEST] <trodis_> tell me what is the best codec + format to stream audio in realtime
[01:25:23 CEST] <trodis_> with ffpmeg and ffserver
[01:25:23 CEST] <BtbN> opus.
[01:25:31 CEST] <trodis_> opus is full of delay
[01:25:36 CEST] <trodis_> i cant get opus to work without delays
[01:25:38 CEST] <BtbN> Use it in low delay mode then.
[01:25:47 CEST] <trodis_> how can u pls pls pls show me how
[01:25:55 CEST] <trodis_> im struggling days with this problems
[01:26:03 CEST] <BtbN> No idea, never used it myself. But i know it exists, various voice-com-tools like mumble and teamspeak use it.
[01:26:04 CEST] <kepstin> even in default mode the delay should only be in the 25msish range...
[01:26:22 CEST] <poisond> there's -tier and -profile, both with main and high parameters. Are those just duplicates?
[01:26:30 CEST] <BtbN> Nope
[01:26:36 CEST] <BtbN> there are tiers and profiles for h265
[01:26:48 CEST] <kepstin> if you're getting delay with opus, it's almost certainly due to buffering somewhere, and it would be a problem regardless of codec.
[01:26:57 CEST] <poisond> BtbN: ok, thanks :)
[01:27:00 CEST] <BtbN> nvenc only supports exactly one profile, so there is no point in messing with that option. It supports diffrents tiers though.
[01:27:04 CEST] <BtbN> For h265
[01:27:10 CEST] <BtbN> For h264 is supports all profiles.
[01:28:23 CEST] <poisond> BtbN: well, at least with libx265 I've gotten some astonishing results size-wise
[01:28:47 CEST] <BtbN> iirc it's already better for 4K stuff
[01:29:56 CEST] <trodis_> im getting a > 5 sec. delay with libopus + ogg
[01:30:06 CEST] <trodis_> let me show u my ffserver.conf
[01:30:11 CEST] <kepstin> trodis_, with what streaming protocol and what player?
[01:30:18 CEST] <trodis_> http and ffplay
[01:30:20 CEST] <kepstin> it's most likely to be player buffering, really :/
[01:30:27 CEST] <BtbN> propably just your player buffering.
[01:30:29 CEST] <trodis_> http://ix.io/ib5
[01:30:44 CEST] <trodis_> ffmpeg -f pulse -i default http://192.168.1.138:8090/feed1.ffm
[01:30:51 CEST] <trodis_> ffplay -nodisp -fflags nobuffer http://192.168.1.138:8090/test.ogg
[01:31:26 CEST] <kepstin> if you want really low delay, you should probably be looking at rtp or something rather than http streaming.
[01:32:10 CEST] <trodis_> can u configure my ffserver.conf so i can use rtp
[01:32:22 CEST] <trodis_> i tried a couple of times with the documentation
[01:32:26 CEST] <trodis_> and failed -.-
[01:33:20 CEST] <BtbN> What are you trying to do that a few seconds delay are that bad?
[01:35:07 CEST] <trodis_> i want to broadcast microphone input, i need a system for interpreting in another language. Right now i have 20 Raspberry pis and one raspberry pi is running ffserver, the interpreter should talk into the microphone and ffmpeg captures the input from the mic and sends it to the ffserver. And the Raspberry pi's should play that
[01:35:33 CEST] <trodis_> by connecting to ffserver
[01:36:36 CEST] <BtbN> yes, RTP or some other udp multicast thing is propably what you want.
[01:37:03 CEST] <trodis_> how does rtp work, can u explain a little, do i need ffserver for rtp?
[01:37:34 CEST] <BtbN> https://trac.ffmpeg.org/wiki/StreamingGuide#StreamingasimpleRTPaudiostreamfromFFmpeg
[01:38:30 CEST] <kepstin> that's a unicast rtp stream, so it'll only send to one client. gets more complex to send it out to multiple clients.
[01:38:53 CEST] <trodis_> yeah that is the whole point using multiple clients
[01:39:05 CEST] <trodis_> i would love to use mumble, but mumble does not offer a cli client
[01:39:24 CEST] <trodis_> and i need a cli low ressource client, because the raspberry pis are my clients
[01:39:29 CEST] <kepstin> if you're on a closed, private network multicast could be an option.
[01:39:38 CEST] <trodis_> yeah it is
[01:39:55 CEST] <trodis_> i will setup a local lan just for this purpose its a public conference
[01:40:06 CEST] <kepstin> in which it's pretty much the same thing, except you send to a multicast address instead of a single client address
[01:40:10 CEST] <trodis_> so one WLAN Router with 300Mbit should be able to handel 20 raspberry pis
[01:40:22 CEST] <kepstin> or broadcast address even
[01:40:32 CEST] <BtbN> wlan isn't multicast capable, as each clients has a seperate encrypted channel.
[01:41:14 CEST] <trodis_> how would you handle this kind of problem
[01:41:30 CEST] <BtbN> I wouldn't use wlan.
[01:41:55 CEST] <trodis_> yeah for cable i had to use a switch
[01:42:02 CEST] <BtbN> exactly.
[01:42:04 CEST] <trodis_> its hard to hide all thoes things
[02:27:09 CEST] <[2]Matoro> hello, is anyone here?
[02:31:00 CEST] <bofh> Hi! I have an mp3 file, I want to get MP4 from this mp4 file and a single image
[02:31:06 CEST] <bofh> ffmpeg -y -loop 1 -i ololo.jpg -i devzen.mp3 -r 30 -b:v 2500k -shortest devzen.mp4
[02:31:09 CEST] <bofh> doesn
[02:31:11 CEST] <bofh> 't work
[02:31:20 CEST] <bofh> Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
[02:33:45 CEST] <trodis_> try -b:v 250k
[02:34:35 CEST] <[2]Matoro> hey
[02:35:08 CEST] <[2]Matoro> just a quick question for anyone who's familiar with AVI, how would you go about adding ttf fonts that an ASS script uses?
[02:35:21 CEST] <bofh> nevermind, specifying -s 540x480 fixed the error
[02:35:32 CEST] <bofh> I still wonder why I couln't get dimensions from jpeg
[02:55:29 CEST] <Freakshow> hello folks& does anyone have any experience with the thread_message_queue message present in v2.6.1 and above?
[02:55:42 CEST] <Freakshow> Ive raised it&and it keeps suggesting I raise it
[02:56:16 CEST] <Freakshow> Im currently using an input from an MPTS unicast source
[07:33:24 CEST] <jookiyaya> can you guys tell the difference between ac3 and dts on DVD-video?
[09:35:09 CEST] <pickled> if i want to output a file to something like x.tmp (instead of x.mp4) how would i do that?
[09:35:42 CEST] <pickled> but the .tmp data is mp4 of course.
[09:36:00 CEST] <relaxed> pickled: -f mp4 x.tmp
[09:36:07 CEST] <pickled> thank you!
[10:44:01 CEST] <kagami_> Hi guys. Does anybody know why VPX_IMG_FMT_HIGHBITDEPTH cannot be enabled via configure? It's used to allow highdepth profiles of VP9.
[10:51:45 CEST] <relaxed> kagami_: did you compile libvpx with --enable-vp9-highbitdepth ?
[10:58:17 CEST] <kagami_> relaxed: I got this error message: --enable-vp9-highbitdepth
[10:58:23 CEST] <kagami_> I'm using latest commit from git
[10:58:35 CEST] <kagami_> oops
[10:58:44 CEST] <kagami_> this one: >Unknown option "--enable-vp9-highbitdepth".
[11:02:50 CEST] <relaxed> no, I meant libvpx's configure
[11:10:24 CEST] <kagami_> relaxed: recompiled libvpx and ffmpeg, now it works. Many thanks!
[11:11:12 CEST] <relaxed> you're welcome
[16:01:51 CEST] <RobotsOnDrugs> are there any good denoisers in ffmpeg?
[16:02:10 CEST] <RobotsOnDrugs> afaict, hqdn3d seems to be the best one in ffmpeg, but it's not that great
[16:02:35 CEST] <trodis_> hi how can i be able to establish low delay connection within this scenario: ffmpeg <-> ffserver <-> 20 ffplay clients
[16:03:26 CEST] <trodis_> i tried libopus and ogg as the container, but the delay is > 5 sec. i turned off the buffering on the ffplay client sides but still no improvement
[16:03:39 CEST] <trodis_> and i activated the Option application lowdelay for libopus
[16:03:41 CEST] <trodis_> still nothing
[16:04:01 CEST] <trodis_> the weird part is, when i use libmp3lame + mp3 format, the delay is only 1 sec
[16:10:24 CEST] <rsevero> In ffserver, can I have 2 streams with different video and/or audio characteristics being feed from the same feed?
[16:28:52 CEST] <djems54> Hi, I had a problem when recording a MP4 file. Now when I want to open it or convert it I have this message:
[16:29:23 CEST] <djems54> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x2568360] moov atom not found 20150425-2108-5-4-1001.mp4: Invalid data found when processing input
[16:29:54 CEST] <djems54> Does anyone help me to fix it ?
[16:30:10 CEST] <djems54> I work on a Debian server
[16:30:31 CEST] <djems54> ffmpeg version 2.6.git Copyright (c) 2000-2015 the FFmpeg developer
[16:41:14 CEST] <BtbN> The process writing the file was interrupted before it could finish writing the header, which is at the end of an mp4 file.
[16:41:19 CEST] <BtbN> Without the moov atom, the file is useless.
[16:41:49 CEST] <BtbN> Don't use mp4 for recording, it's a horrible container.
[16:43:33 CEST] <albru123> This might be an AviSynth question rather than ffmpeg, but is ffdshow used by default if I use DirectShowSource() in AviSynth script? I'm encountering some kind of a bug, leading to skipping of first few frames in the video (like 50 or so)
[16:50:03 CEST] <djems54> @BtbN : yes, the process was interrupted
[16:50:23 CEST] <BtbN> yes, the file is lost then.
[16:51:01 CEST] <djems54> What would be the best alternative as container ?
[16:51:31 CEST] <djems54> there is no way to recover the file?
[16:51:34 CEST] <BtbN> flv, mkv
[16:51:50 CEST] <djems54> Ok, MKV with the same codec
[16:51:51 CEST] <BtbN> Also, don't interrupt the process
[17:01:44 CEST] <djems54> there is no way to recover the existing file?
[17:04:34 CEST] <c_14> djems54: you can try https://github.com/ponchio/untrunc . May or may not work.
[17:04:36 CEST] <hendry> is there a ffmpeg one liner for creating a HLS or DASH stream from v4l? http://stackoverflow.com/q/29935731/4534
[17:07:08 CEST] <djems54> c_14: i will try your link, thanks
[17:11:24 CEST] <djems54> untrunc doesnt work :(
[18:06:57 CEST] <inetd50> hi
[18:07:30 CEST] <inetd50> im trying to stream a video file using ffmpeg, but is there a way to loop the file?
[18:09:29 CEST] <mccoy_slack> while /bin/true; do .... ffmpeg stuf... ; done
[18:10:01 CEST] <c_14> Not perfect since ffmpeg will close and reopen the output stream.
[18:11:44 CEST] <mccoy_slack> true
[18:13:24 CEST] <average> hey
[18:13:35 CEST] <average> any planet.ffmpeg.org or something like that ?
[18:14:08 CEST] <c_14> hmm?
[18:14:28 CEST] <average> c_14: planet.debian.org for example has news about debian
[18:14:28 CEST] <inetd50> c_14 exactly.. i want it to be smooth loop
[18:14:45 CEST] <inetd50> c_14: how come ffmpeg doesnt allow looping out of the box
[18:15:04 CEST] <inetd50> i cannot find anything on the internet that allow me to loop seemlessly
[18:15:11 CEST] <c_14> inetd50: nobody implemented it yet
[18:15:24 CEST] <inetd50> dam
[18:15:36 CEST] <inetd50> can it be done outside of ffmpeg?
[18:15:41 CEST] <inetd50> using other tools
[18:16:09 CEST] <inetd50> like ffplay or some other way then pipe to ffmpeg
[18:16:17 CEST] <c_14> average: there's a news section on https://ffmpeg.org/index.html#news
[18:16:39 CEST] <c_14> inetd50: you could create a really long concatfile and use the concat demuxer
[18:16:53 CEST] <c_14> It won't be infinite, but you could easily make it n years long.
[18:17:12 CEST] <average> c_14: yeah but that's just news from ffmpeg's team
[18:17:20 CEST] <average> c_14: i'm also interested in an RSS aggregator about ffmpeg
[18:17:32 CEST] <average> where it would collect what people around the web say and do with ffmpeg
[18:17:52 CEST] <c_14> inetd50: You might even be able to make it infinite. Not sure if the demuxer cares if the file is finite.
[18:17:54 CEST] <inetd50> inetd50: i tried the concat demuxer...but the output file doesnt seem to work properly with my hardware encoder :|
[18:17:55 CEST] <c_14> average: nothing I know of
[18:18:40 CEST] <average> ok
[18:18:44 CEST] <inetd50> c_14: any sample cli you can recommend?
[18:19:23 CEST] <c_14> inetd50: hmm?
[18:19:35 CEST] <c_14> example cli for what?
[18:20:25 CEST] <c_14> s/example/sample/
[18:23:08 CEST] <inetd50> c_14: concat demuxer...
[18:24:27 CEST] <c_14> https://trac.ffmpeg.org/wiki/Concatenate
[18:24:42 CEST] <c_14> Look at the examples for generating the file with loops.
[18:25:05 CEST] <average> what ffmpeg blogs do you guys read though ?
[18:25:10 CEST] <c_14> Just that instead of find or for file in; you'd either add the same file n times
[19:55:10 CEST] <kathy_> hello, i want to convert a 10hr youtube video to audio. using youtube-dl i can extract audio after download. Is there a way to use ffmpeg and do it as it streams
[19:57:35 CEST] <sfan5> kathy_: you can tell youtube-dl to download only the audio
[19:58:12 CEST] <jonet> I'm trying to use libarchive along with ffmpeg to read metadata from compressed files, never used ffmpeg library before so I'm very fresh with this.
[19:58:54 CEST] <kathy_> sfan5: i think that is part of post processing only though. AFAIK. so a 10 hr long video might take a lot of time that way
[19:59:30 CEST] <sfan5> i don't think it's part of the post processing
[19:59:38 CEST] <jonet> I'm trying to use a AVIOContext with some methods to read and seek forward in the archive which seems to work fine since the read function is clearly executed, but after a few reads it segfaults.
[20:00:18 CEST] <jonet> Also, I can't really find ... Well, any documentation for libav* at all, except from the autogenerated API docs.
[20:02:02 CEST] <jonet> Here's my code; https://gist.github.com/wolfhechel/860e557ef26ef46b7c0a
[20:02:06 CEST] <sfan5> kathy_: when i pass -f 141 to youtube-dl it shows a smaller filesize than downloading the whole video
[20:03:57 CEST] <kathy_> sfan5:  https://github.com/rg3/youtube-dl/blob/master/README.md#readme    (it says extract audio -x in post processing)
[20:04:40 CEST] <sfan5> kathy_: thats a different option, -f 141 only downloads the audio, -x seems to extract it after downloading everything
[20:04:54 CEST] <kathy_> sfan5: what is 141 for?
[20:05:11 CEST] <sfan5> kathy_: 141          m4a        audio only DASH audio  255k , m4a_dash container, aac  @256k (44100Hz), 9.08MiB
[20:05:21 CEST] <sfan5> (-F flags shows the available formats)
[20:05:59 CEST] <kathy_> sfan5: thanks! if i want to convert this to ogg format with ffmpeg while it streams?
[20:09:56 CEST] <sfan5> kathy_: youtube-dl -q -f 141 "VIDEO_URL" -o /dev/stdout | ffmpeg -i - -c:a libvorbis -q:a 4 -y out.ogg
[20:09:59 CEST] <sfan5> that works for me
[20:10:29 CEST] <sfan5> the only problem is that ffmpeg waits for more input after the audio ends
[20:12:56 CEST] <sfan5> kathy_: this one works better: youtube-dl -f 141 "video_url" -o - | ffmpeg -i - -c:a libvorbis -q:a 4 -y out.ogg
[20:13:11 CEST] <sfan5> youtube-dl will throw an error after it finishes
[20:13:18 CEST] <sfan5> that's fine as long as the audio file is ok
[20:15:46 CEST] <kathy_> sfan5: since the audio is huge.(10 hrs) is there a way to download it in chunks. manually give start and finish times .
[20:16:32 CEST] <sfan5> no idea, i don't know of any way to do that
[20:16:54 CEST] <kathy_> sfan5:  ok . thanks ! :)
[20:18:46 CEST] <PieterMX> Hi
[20:20:10 CEST] <PieterMX> Anyone with experience in HLS configuration for ffserver?
[20:23:00 CEST] <PieterMX> It seems I can't set hls_time etc., and the codec is giving me:
[20:23:01 CEST] <PieterMX> Wed Apr 29 20:16:53 2015 [hls @ 0x312c3f0]failed to rename file .tmp to
[20:23:04 CEST] <maqr> PieterMX: i'm currently fighting with HLS, but i'm not using ffserver
[20:23:33 CEST] <PieterMX> hi maqr, using ffmpeg directly?
[20:23:37 CEST] <maqr> PieterMX: yeah
[20:23:44 CEST] <maqr> PieterMX: you on osx?
[20:23:49 CEST] <PieterMX> debian
[20:23:58 CEST] <PieterMX> or at least the server is :)
[20:24:10 CEST] <maqr> PieterMX: got osx available? you'll need mediastreamvalidator
[20:24:17 CEST] <maqr> i'm not sure if it's available on any other platforms
[20:24:25 CEST] <maqr> PieterMX: i'll gist what i'm doing for you to take a look at though, sec
[20:25:00 CEST] <PieterMX> apple's mediastreamvalidator?
[20:26:00 CEST] <maqr> PieterMX: yeah
[20:26:08 CEST] <maqr> PieterMX: this is how i'm testing https://gist.github.com/anonymous/f5c824696e9213025fa3
[20:26:15 CEST] <PieterMX> I have OS X over here
[20:26:47 CEST] <PieterMX> lets see if my apple dev account is still active
[20:27:10 CEST] <maqr> PieterMX: i have an input.mp4, that hls.m3u8, and my transcode.sh in the directory... it runs the ffmpeg command, spawns a test http server from the directory, then tries to validate it with mediastreamvalidator
[20:27:39 CEST] <maqr> PieterMX: my goal is to get the validator to pass, and i'm in a lot better shape than yesterday, but the bitrates are still wrong
[20:27:44 CEST] <PieterMX> mediastreamvalidator is not installed by default is it?
[20:27:53 CEST] <maqr> nope
[20:28:24 CEST] <maqr> PieterMX: https://developer.apple.com/streaming/ link on the right, but you need to log in to get it
[20:28:52 CEST] <PieterMX> I'm signed in but cant find the download :S
[20:29:01 CEST] <PieterMX> it says "no records" lol
[20:29:30 CEST] <maqr> PieterMX: i can host the dmg for you if you want
[20:29:53 CEST] <maqr> PieterMX: you shouldn't run untrusted binaries but https://dl.dropboxusercontent.com/u/19471040/streamingtools_beta194_signed.dmg
[20:29:58 CEST] <maqr> i think the dmg is signed somehow
[20:30:01 CEST] <maqr> or maybe you can google the hash or something
[20:30:15 CEST] <maqr> i get so frustrated with apple
[20:30:41 CEST] <PieterMX> cant do sorry, should be somwhere on that site let me look
[20:31:24 CEST] <maqr> PieterMX: does this work for you? http://adcdownload.apple.com/QuickTime/http_live_streaming_tools/streamingtools_beta194_signed.dmg
[20:31:39 CEST] <maqr> maybe try it with a browser that's logged in to somewhere else on apple's dev site
[20:31:42 CEST] <PieterMX> You may be a member of a program that does not include this page as a benefit.
[20:31:43 CEST] <PieterMX> lol
[20:31:58 CEST] <maqr> :/
[20:33:17 CEST] <maqr> PieterMX: you need that tool either way, but are you doing live HLS or serving static videos as HLS?
[20:33:46 CEST] <PieterMX> live
[20:34:04 CEST] <maqr> ah, i'm trying to do static, i guess we have different problems then, i'm stuck on wrong bitrates coming out of the transcoding
[20:34:16 CEST] <maqr> you still need to validate your live stream with the validator though
[20:44:05 CEST] <jonet> Actually nevermind, I was reading really old material. Once I just simplified the whole thing with the avio_read example it went smooth as silk.
[20:48:59 CEST] <maqr> does it ever make sense for bufsize to be smaller than the target rate?
[20:49:06 CEST] <maqr> i've read the docs, but i'm still not very clear on what bufsize actually is
[20:49:46 CEST] <Mavrik> Size of player's buffer
[20:50:10 CEST] <Mavrik> And it makes sense if the players buffer holds less than 1 sec video
[20:50:52 CEST] <maqr> Mavrik: that still doesn't make sense to me... does a smaller bufsize mean more headers or something?
[20:51:08 CEST] <maqr> like are they actually separate chunks inside of the TS files?
[20:51:12 CEST] <Mavrik> No.
[20:51:39 CEST] <Mavrik> Encoder keeps track of how the buffer is filled while encoding and will overshoot maxrate if it has to
[20:51:52 CEST] <Mavrik> And then drop under maxrate to make sure player's buffer refills
[20:52:10 CEST] <maqr> yeah, i'm overshooting now and failing HLS validation... so it sounds like i need a smaller bufsize
[20:52:30 CEST] <PieterMX> hmmz, cant find the source of "[hls @ 0x313b6f0]failed to rename file .tmp to " (in an attempt to analyze)
[20:52:31 CEST] <Mavrik> It's... not that simple
[20:52:32 CEST] <maqr> Mavrik: what's the smallest possible bufsize?
[20:53:35 CEST] <Mavrik> Hrmf, no idea.
[20:53:59 CEST] <Mavrik> What is "HLS" validation you're talking about?
[20:54:12 CEST] <maqr> Mavrik: apple's mediastreamvalidator
[20:54:17 CEST] <Mavrik> Since having an accurate bufsize will increase quality
[20:54:23 CEST] <Mavrik> So I dunno what kind of dumb software are you using
[20:54:24 CEST] <maqr> hmm
[20:54:27 CEST] <maqr> apple's dumb software
[20:54:46 CEST] <maqr> Mavrik: does greater bufsize increase quality?
[20:54:49 CEST] <maqr> i'm not sure what you mean by 'accurate'
[20:54:57 CEST] <maqr> or maybe the right quesiton is, how can i find the accurate bufsize for my stream?
[20:55:08 CEST] <PieterMX> what is the framerate?
[20:55:13 CEST] <PieterMX> i mean
[20:55:14 CEST] <PieterMX> bitrate
[20:55:27 CEST] <Mavrik> maqr, uh, was I unclear?
[20:55:35 CEST] <Mavrik> maqr, bufsize -> set PLAYER's buffer size
[20:55:41 CEST] <maqr> Mavrik: maybe, or i'm dense...
[20:55:48 CEST] <Mavrik> set accurately -> set it to value your video player uses
[20:55:53 CEST] <Mavrik> that is how much video it'll buffer
[20:55:53 CEST] <maqr> OH
[20:55:59 CEST] <Mavrik> it can be smaller though :)
[20:56:07 CEST] <Mavrik> but if it's larger you can get stuttering
[20:56:34 CEST] <Mavrik> maqr, for starters setting it to the same value as maxrate is usually good enough, since pretty much all players will buffer at least a second
[20:56:36 CEST] <maqr> Mavrik: i think it's related to hls_time then
[20:57:06 CEST] <maqr> err, wait, i guess they're separate
[20:57:10 CEST] <PieterMX> which cant be set in ffserver somehow :S
[20:58:24 CEST] <PieterMX> error is part of libavformat
[20:58:31 CEST] <maqr> Mavrik: https://gist.github.com/anonymous/4440431a27196dabd85e
[20:58:49 CEST] <maqr> Mavrik: if i use a bufsize shorter than 1 sec, it seems to reduce some of these segment bandwidth warnings
[20:59:04 CEST] <maqr> but that doesn't make sense to me, because i have an HLS time of 10 sec
[21:00:02 CEST] <maqr> Mavrik: i've already trimmed off 10% from the target bitrate because of TS overhead
[21:00:30 CEST] <maqr> Mavrik: i also don't think it's a coincidence that 24 is the last TS file and that's where the warning is
[21:01:36 CEST] <maqr> ya, that last TS file is super small, maybe i should just ignore this warning
[21:02:23 CEST] <Mavrik> hmm
[21:02:36 CEST] <maqr> the last TS file is under 2 seconds, which i bet is why there's a warning here, because maybe apple's tool is validating wrong
[21:03:13 CEST] <maqr> Mavrik: what's also surprising to me though is that apple's tool reports bitrates that are higher than the maxrate
[21:03:20 CEST] <maqr> Segment bitrate: Average:  1.53 Mbits/sec, Max:  1.95 Mbits/sec
[21:03:21 CEST] <Mavrik> yeah, because it probably is
[21:03:26 CEST] <Mavrik> but if your segment is 2 seconds
[21:03:34 CEST] <Mavrik> then x264 probably won't even stabilize it's bitrate enough
[21:03:40 CEST] <maqr> and that's with me setting 1350k
[21:03:54 CEST] <maqr> Mavrik: i thought maxrate was the max rate...
[21:05:01 CEST] <maqr> "Set maximum bitrate tolerance (in bits/s). Requires bufsize to be set. (from INT_MIN to INT_MAX)"
[21:05:19 CEST] <maqr> i bet if i cut the bufsize down to half a second, i won't get these warnings
[21:05:43 CEST] <maqr> but i don't really understand why
[21:05:44 CEST] <maqr> trying it now
[21:08:13 CEST] <maqr> Mavrik: yeah, check this out, half-second bufsize, no warnings: https://gist.github.com/anonymous/6f0aa2fd5f7a115899a6
[21:08:58 CEST] <maqr> i don't understand why though... even the segment in question was almost 2 seconds, and the previous bufsize was 1 second
[21:09:12 CEST] <maqr> maybe it couldn't fill a whole second buffer and somehow that made the rate go over
[21:10:13 CEST] <maqr> i bet that's what's happening
[21:10:48 CEST] <Mavrik> As I said, your segments are probably too small for reliable bitrate setting.
[21:11:18 CEST] <maqr> yeah, i think there's always going to be a warning on the last one
[21:13:12 CEST] <maqr> i think i'm understanding this now :)
[21:14:51 CEST] <maqr> Mavrik: the only thing that's still really unclear to me is why the 264k average bitrate is farther from the target bitrate than the others
[21:16:45 CEST] <Mavrik> the difference between I-frame and other P/B frames is more pronounced at lower bitrates
[21:17:13 CEST] <maqr> Mavrik: is there a setting i should tweak to deal with that or just lower my bitrate until i get closer to the target?
[21:17:13 CEST] <Mavrik> and x264 doesn't have enough time to compensate
[21:17:37 CEST] <Mavrik> Honestly you should probably encode full video to each quality and slice it afterwards
[21:17:42 CEST] <Mavrik> or do it directly
[21:17:50 CEST] <Mavrik> not transcode individual segments
[21:18:06 CEST] <maqr> wait, i thought that's what it was doing
[21:18:14 CEST] <maqr> that must be what it's doing
[21:18:43 CEST] <maqr> it's the built-in HLS stuff that's splitting out to multiple TS files, i'm not actually sure how it works
[21:19:21 CEST] <maqr> "Output #1, hls, to 'ts/264k-400x300.m3u8'", i think it should be doing the transcode first then splitting it though, it knows about the whole m3u8 upfront
[21:19:51 CEST] <kepstin-laptop> maqr, you're splitting based on time, and using a vbv buffer of ~1s?
[21:20:12 CEST] <kepstin-laptop> if so, the bitrate for any particular segment will be slightly more or less than the average, nothing really wrong with that.
[21:20:23 CEST] <maqr> kepstin-laptop: yeah
[21:20:27 CEST] <maqr> hmm
[21:20:38 CEST] <maqr> kepstin-laptop: for a particular segment yeah, but for the whole stream it should be close to the target
[21:20:59 CEST] <kepstin-laptop> yeah.
[21:21:03 CEST] <Mavrik> maqr, hrmf, you're right, I overlooked the cmd line :)
[21:21:28 CEST] <maqr> i'm trying again with a bufsize of 10*bitrate, because my hls_time is 10
[21:21:54 CEST] <maqr> i would think that would make each TS file about the right size
[21:22:03 CEST] <maqr> *about the right rate
[21:22:56 CEST] <kepstin-laptop> that basically means that you're expecting the player to buffer 10*bitrate amount of stuff before starting to play the video, and can sustain a download speed of bitrate.
[21:23:10 CEST] <kepstin-laptop> (modulo overheads and whatnot)
[21:23:33 CEST] <maqr> kepstin-laptop: yeah, that's probably not what i want in production, but i'd think it would at least get all the files to the right rate
[21:23:38 CEST] <maqr> hrm, and it doesn't
[21:23:45 CEST] <kepstin-laptop> that will probably give you more variation
[21:23:59 CEST] <maqr> it does, yeah
[21:24:01 CEST] <kepstin-laptop> the bigger the vbv buffer, the more the encoder can move bits around between frames
[21:24:18 CEST] <kepstin-laptop> which might move them between segments if you're splitting only based on time.
[21:24:25 CEST] <kepstin-laptop> that's expected and normal.
[21:24:31 CEST] <maqr> kepstin-laptop: 1 second seems like it should be a reasonable amount then, given that my TS target sizes are 10s (even though they're actually all over the place)
[21:25:16 CEST] <kepstin-laptop> target duration, not target size :)
[21:25:40 CEST] <maqr> heh, sorry, the terminology is hard :)
[21:26:12 CEST] <kepstin-laptop> since x264 doesn't know about where the boundaries of the segments are, the vbv setting is allowing it to borrow bits from previous or next segments.
[21:26:33 CEST] <kepstin-laptop> either way, as long as the player maintains a download speed of at least bitrate+overheads, it'll be fine.
[21:26:51 CEST] <maqr> kepstin-laptop: that part makes sense, yeah, but how does it decide where to split the TS files? they mostly seem to be between 6 and 12 seconds
[21:27:16 CEST] <kepstin-laptop> maqr, hmm. it might be trying to split them to start on a keyframe?
[21:27:31 CEST] <maqr> how often are keyframes usually?
[21:27:49 CEST] <kepstin-laptop> how ever often you set them to, and more often if a scene change is detected.
[21:27:57 CEST] <maqr> oh, right, that makes sense
[21:28:51 CEST] <kepstin-laptop> i dunno if that's what the splitter is actually doing tho, i haven't looked closely at it
[21:29:44 CEST] <maqr> also, does it make sense to set -b:v to the same as maxrate?
[21:30:00 CEST] <maqr> in my head that makes sense, because i'm thinking of -b:v as the target bitrate and i don't want to exceed the maxrate
[21:30:12 CEST] <maqr> but maybe there's a pitfall there
[21:30:14 CEST] <kepstin-laptop> maqr, yes, I think that makes sense.
[21:30:45 CEST] <kepstin-laptop> (there's some special cases where you might want maxrate to be higher - but that's mostly limited to authoring to optical disks)
[21:32:37 CEST] <kepstin-laptop> (e.g. "to fit on the disk, I have to encode to 2mbit average, and the disk drive can read at max 5mbit/s")
[21:32:58 CEST] <maqr> oh, that make sense
[21:33:18 CEST] <maqr> kepstin-laptop: i'm running my transcodes again with more sensible settings, i'll post the output in a minute when it's done
[21:36:27 CEST] <maqr> kepstin-laptop: check this out, it's damn close https://gist.github.com/anonymous/e1ee814cda77da4c0466
[21:36:58 CEST] <maqr> for the 1500k video + 128k audio target, i'm averaging 1.69mbit instead of 1.63mbit, so i think that's good
[21:37:12 CEST] <maqr> and i can ignore the warning on the last TS file because if it was padded out to the full 10 seconds, i'm sure that warning wouldn't be there
[21:37:20 CEST] <maqr> same with the 728k stream
[21:37:31 CEST] <maqr> the 264k one though... i need to adjust something to bring that down
[21:37:51 CEST] <maqr> "Segment bitrate: Average: 314.38 kbits/sec (exceeds target by 19.08 %), Max: 369.39 kbits/sec (exceeds target by 39.92 %)"
[21:38:12 CEST] <maqr> i could take 20% off the target bitrate, but that seems a bit brutish... i'm guessing there's some other config setting i can tweak to get closer to the target?
[21:38:54 CEST] <kepstin-laptop> hard to say. your bitrate is so low that a fairly small difference is a big percentage.
[21:39:20 CEST] <maqr> yeah
[21:39:38 CEST] <maqr> but it seems like it's consistently higher across the whole stream
[21:40:04 CEST] <maqr> if i reduce it to 160k instead of 200k, i bet it's going to be totally fine, but i don't really understand why that's a fix
[21:40:56 CEST] <kepstin-laptop> your bufsize is 1500k, and each segment is only 250kish
[21:41:22 CEST] <kepstin-laptop> so the encoder basically expects the decoder to be holding 6 segments in buffer at a time, hmm.
[21:41:26 CEST] <maqr> kepstin-laptop: bufsize is 200k for the 200k stream
[21:41:35 CEST] <maqr> "-s 400x300 -c:v libx264 -preset:v medium -level:v 3.0 -profile:v baseline -b:v 200k -maxrate 200k -bufsize 200k -framerate 12 -b:a 64k -ar 44100 -ac 2 -c:a libfdk_aac -profile:a aac_he_v2 -hls_time 10 -hls_list_size 0 ts/264k-400x300.m3u8 "
[21:41:54 CEST] <kepstin-laptop> oh, hmm.
[21:42:11 CEST] <kepstin-laptop> you're only getting the warnings on the small stream, i didn't realize there were multiples there.
[21:42:21 CEST] <maqr> ah, yeah, sorry if i was unclear
[21:42:45 CEST] <maqr> there's a 64k audio only stream, a 200k video stream, a 600k video stream, and a 1500k video stream
[21:42:56 CEST] <maqr> the 200k video also has 64k audio
[21:43:08 CEST] <maqr> the 600k and 1500k videos have 128k audio
[21:43:36 CEST] <kepstin-laptop> hmm. encoding to 200k bitrate, there's ~50k overhead, I'd expect that to work.
[21:44:03 CEST] <kepstin-laptop> it's averaging 314 over the entire stream rather than the desired 264.
[21:44:26 CEST] <maqr> kepstin-laptop: yeah, and the 64k-audio-only stream seems fine, so i think it's not having a problem with the audio side
[21:44:30 CEST] <maqr> i think it's a problem on the video side
[21:45:26 CEST] <kepstin-laptop> oh, there's audio and video in the same stream?
[21:45:50 CEST] <kepstin-laptop> 200 video + 64 audio + 56 overhead = 314
[21:45:54 CEST] <kepstin-laptop> there's the math.
[21:46:05 CEST] <kepstin-laptop> well, not exactly, but it's close
[21:46:41 CEST] <maqr> kepstin-laptop: i think the overhead is broken out separately though?
[21:46:48 CEST] <maqr> ohhh, i see what you mean
[21:47:09 CEST] <kepstin-laptop> the "Average segment structural overhead: 53.13 kbits/sec (16.90 %)" means that you only have 210kbit/s total to use for audio+video if you want the final file size to hit the target
[21:47:32 CEST] <maqr> kepstin-laptop: so should i reduce my target rates by the size of the overhead?
[21:48:02 CEST] <maqr> even for the other streams, i bet that would get me closer to the target rates
[21:48:38 CEST] <maqr> so i can take 10% off the 1500k stream, 12% off the 600k stream, and 17% off the 200k stream, and i should be good?
[21:49:17 CEST] <kepstin-laptop> maqr, something around that should be good, yeah
[21:49:25 CEST] <kepstin-laptop> man, ts has a lot of overhead :/
[21:49:54 CEST] <maqr> yeah, i read that's because it was meant for dvd players and stuff
[21:50:03 CEST] <maqr> and people are petitioning apple to let HLS use something besides TS
[21:52:19 CEST] <kepstin-laptop> is your plan to have seamless switching between different bitrates in the player?
[21:52:24 CEST] <maqr> kepstin-laptop: yeah
[21:52:27 CEST] <kepstin-laptop> because right now that won't work
[21:52:46 CEST] <maqr> kepstin-laptop: why? they're all the same audio samplerate
[21:53:00 CEST] <maqr> which i thought is what made that seemless, but i might be missing something
[21:53:02 CEST] <kepstin-laptop> to do that, i think (haven't confirmed this) that you need the video keyframes in matching positions in each video stream.
[21:53:20 CEST] <maqr> hmm
[21:53:24 CEST] <kepstin-laptop> right now, x264 is independently deciding on the position in each stream.
[21:53:45 CEST] <maqr> kepstin-laptop: i've read a lot about this and haven't stumbled on that gem yet... any idea where you saw that?
[21:54:20 CEST] <maqr> kepstin-laptop: i guess i could just set a keyframe interval somehow, and because they're all the same length, that might be fine?
[21:54:29 CEST] <kepstin-laptop> i think it depends on the player; but if you're switching quality by downloading e.g. segment 10 at one quality then segment 11 at a different quality, and the segment times don't match exactly, there'll be a jump.
[21:54:59 CEST] <maqr> kepstin-laptop: i thought the iOS player would take care of that for me, but that's one of the things i need to test today, so we'll find out :)
[21:55:02 CEST] <kepstin-laptop> maqr, you'd have to set a keyframe interval, and disable x264's automatic scene change keyframes.
[21:55:17 CEST] <maqr> kepstin-laptop: any idea what parameters those are so i'm looking up the right thing?
[21:55:17 CEST] <kepstin-laptop> be worth testing to see; i'm not sure either way. haven't done this myself :)
[21:56:34 CEST] <maqr> kepstin-laptop: btw, reducing by the overhead % on each stream seemd to work well: https://gist.github.com/anonymous/842444bdd9da2bb833a0
[21:56:37 CEST] <kepstin-laptop> I think setting the ffmpeg -g option (to e.g. 10*framerate) and the "no-scenecut" x264 option (via -x264opts) should do it.
[21:57:05 CEST] <maqr> ok, thanks, i'll try that if it doesn't switch cleanly
[21:57:24 CEST] <kepstin-laptop> actually, the "-sc_threshold 0" ffmpeg option might work there.
[21:57:40 CEST] <maqr> kepstin-laptop: oh, but i bet only the video would jump, because there's also an audio-only stream, and there was a note about how sample rates need to be the same to prevent an audible skip when changing quality levels
[21:57:57 CEST] <maqr> and the aac streams are still the same, no keyframes there (afaik, anyway)
[21:58:05 CEST] <kepstin-laptop> maqr, right, but if the hls segments are being cut based on video keyframes...
[21:58:54 CEST] <maqr> oh, right
[21:58:54 CEST] <maqr> hmm
[21:59:16 CEST] <maqr> figuring out how to test this is a bit tricky too
[21:59:16 CEST] <maqr> heh
[22:00:37 CEST] <kepstin-laptop> yeah, since you're dealing with software you don't really control on a locked down device :/
[22:00:47 CEST] <maqr> yeah, super frustrating
[22:00:47 CEST] <maqr> heh
[22:01:28 CEST] <kepstin-laptop> if you have it connected to wifi on a router running a full linux like openwrt, you might be able to play with the wifi router to apply rate limiting on the connection.
[22:01:59 CEST] <maqr> that's actually a great suggestion, i have dd-wrt on my router
[22:02:13 CEST] <maqr> i was going to try throttling with Charles Proxy, but i think that's a different kind of throttling that involves buffering somehow
[22:02:17 CEST] Action: kepstin-laptop did that on his open "guest" network at home; and kind of pities the people who get barely faster than dialup speeds when they try to use it.
[22:02:36 CEST] <maqr> heh
[22:03:21 CEST] <kepstin-laptop> you'd want to use a separate router for this testing that's not actually running your real internet connection tho :)
[22:03:23 CEST] <maqr> kepstin-laptop: for the m3u8, they say bandwidth is "The value is a decimal-integer of bits per second. It must be an upper bound of the overall bitrate of each media file, calculated to include container overhead, that appears or will appear in the playlist."
[22:03:52 CEST] <maqr> so for the 264k one i have BANDWIDTH=264000
[22:04:22 CEST] <kepstin-laptop> hmm, fun, an upper bound that applies to each segment individually :/
[22:04:23 CEST] <maqr> i wonder if "overall bitrate, calculated to include container overhead" means that i'm ok with "Segment bitrate: Average: 278.11 kbits/sec, Max: 321.02 kbits/sec (exceeds target by 21.60 %)"
[22:04:35 CEST] <maqr> well, it says "overall bitrate", so maybe that means average...
[22:04:40 CEST] <maqr> maybe it's an upperbound on an average
[22:04:41 CEST] <maqr> because apple
[22:05:00 CEST] <maqr> that's from https://developer.apple.com/library/ios/technotes/tn2288/_index.html if you're curious
[22:06:02 CEST] <maqr> i think the wording is really ambiguous
[22:06:11 CEST] <kepstin-laptop> "calculated to include container overhead" means that you have to calculate the container overhead in when picking media bitrates :)
[22:06:26 CEST] <maqr> the RFC draft is a bit clearer: "It MUST be an upper bound of the overall bitrate of each media file, calculated to include container overhead, that appears or will appear in the Playlist.
[22:06:34 CEST] <maqr> well, i'm way off then
[22:06:56 CEST] <maqr> kepstin-laptop: it sounds like i actually need ffmpeg to be 100% sure it never goes over the max bitrate? somehow?
[22:07:11 CEST] <kepstin-laptop> i'd expect in most cases, an individual segment being over that amount will actually work... as long as the connection speed is slightly higher than the requested stream bitrate
[22:07:27 CEST] <maqr> yeah, quite likely
[22:07:30 CEST] <kepstin-laptop> which is why ffmpeg is using a 10% tolerance by default
[22:07:45 CEST] <maqr> kepstin-laptop: where?
[22:07:54 CEST] <kepstin-laptop> "WARNING: Media segment bandwidth exceeded target playlist bandwidth by 18 % (312.10 kbits/sec vs.264.00 kbits/sec, limit is 10 %)."
[22:08:04 CEST] <maqr> oh no, that's apple's validator tool output, not ffmpeg
[22:08:04 CEST] <kepstin-laptop> it doesn't show that message if the difference is <10%
[22:08:13 CEST] <kepstin-laptop> oh, interesting.
[22:08:28 CEST] <maqr> i got that by doing "mediastreamvalidator http://localhost:8090/hls.m3u8"
[22:08:38 CEST] <kepstin-laptop> so apple's validator tool is basically saying that this isn't really a "MUST" ;)
[22:08:52 CEST] <maqr> kepstin-laptop: here's what i'm actually doing https://gist.github.com/anonymous/3ca617420e5c3b1abd4a
[22:08:59 CEST] <maqr> yeah, it seems that way
[22:09:18 CEST] <maqr> but i'm still having a hard time understanding why i can't force ffmpeg to honor a max rate
[22:09:40 CEST] <maqr> maybe i could if i did two-passes?
[22:10:08 CEST] <kepstin-laptop> but yeah, if your average overall stream bitrate (including overhead, which you have to calculate yourself) is the m3u8 bitrate, and no segment is >10% above the m3u8 bitrate, you're fine
[22:10:26 CEST] <kepstin-laptop> so just include the overhead when calculating video and audio bitrate and you're set for that.
[22:11:02 CEST] <kepstin-laptop> dunno if two-pass would help here - i dunno how it interacts with using a vbv buffer.
[22:11:16 CEST] <maqr> yeah, this is probably good enough
[22:11:28 CEST] <kepstin-laptop> in normal mode, x264 two-pass works by the first pass calculates a crf, then second pass does a crf encode.
[22:11:46 CEST] <maqr> kepstin-laptop: i haven't tried CRF yet, but that could also be an option here...
[22:11:51 CEST] <kepstin-laptop> it's designed to *maximize* the bitrate variation, to keep quality constant
[22:11:56 CEST] <maqr> though i'm not sure what i'd set the rate factor to in this case
[22:11:59 CEST] <kepstin-laptop> the opposite of what you want here
[22:12:07 CEST] <maqr> yeah, true
[22:12:11 CEST] <kepstin-laptop> you want the bitrate to stay constant, and quality to vary
[22:12:24 CEST] <maqr> kepstin-laptop: maybe i should set a minrate too?
[22:12:31 CEST] <maqr> would that somehow force it into a more constant mode?
[22:12:43 CEST] <kepstin-laptop> nah, that would just make it waste bits
[22:13:04 CEST] <kepstin-laptop> only useful if for some reason you have a minimum transmission unit size, i think
[22:13:28 CEST] <maqr> yeah, that's what i'd think too
[22:13:31 CEST] <kepstin-laptop> i dunno if you need it for some types of satellite or radio broadcasting?
[22:13:33 CEST] <kepstin-laptop> maybe?
[22:14:16 CEST] <kepstin-laptop> for online video, if it doesn't need the full bitrate then you just saved someone a couple bucks on their cell phone bill, right? :)
[22:14:32 CEST] <maqr> kepstin-laptop: yeah, that's what i'd think too, unless setting it makes ffmpeg go more strict with staying at the requested bitrate
[22:14:35 CEST] <maqr> i'm testing it now to be sure
[22:15:19 CEST] <kepstin-laptop> I'd expect it not to make much difference at that low of a bitrate, since x264 is probably using as much as it can at all times anyways.
[22:16:22 CEST] <maqr> kepstin-laptop: yeah, pretty much no difference
[22:17:46 CEST] <maqr> kepstin-laptop: ok, i'm gonna go grab lunch, then figure out how this theoretically correct-ish HLS (though not really draft RFC compliant) actually works on a real iOS device
[22:17:51 CEST] <maqr> thanks so much for your help, much appreciated
[22:19:20 CEST] <maqr> i'll let you know it goes
[22:20:33 CEST] <kepstin-laptop> cool, i'd be curious to know
[22:33:44 CEST] <rikai> Hm, can anyone tell me why adding subtitles to a video might cause the audio to desync? I can encode this video fine, but the moment i add subs i get weird pauses in the audio...
[22:47:23 CEST] <__jack__> rikai: encoding, you mean muxing right ? the process is fast sure ?
[22:49:22 CEST] <rikai> I suppose so, yeah. :)
[22:51:06 CEST] <__jack__> can you pastebin the line & execution ?
[22:52:13 CEST] <SpeakerToMeat> Hello.
[22:52:43 CEST] <rikai> Ah, hm... interesting... if i use -c:s copy, it works fine. But if i let ffmpeg do what i want with the subtitle stream it messes things up.
[22:52:48 CEST] <rikai> Hold, i'll post both up.
[22:53:56 CEST] <SpeakerToMeat> Question, can one mux (remux, copy) ProRes 4444 video using ffmpeg (on linux)? the codec doesn't need to be understood since it's not being recompressed, but the codec id should be set correctly on the quicktime destination file for the track.
[23:00:08 CEST] <rikai> Ah no, i was mistaken, still desynced.
[23:00:24 CEST] <rikai> __jack__: http://pastie.org/pastes/10121019/text?key=su7aygntwrqkmwllfldlmw
[23:08:58 CEST] <rikai> The warning about global headers appears to be irrelevant, because it happens even if i don't copy streams. I can only assume it's tied to the subs somehow. I've actually been trying to figure out how to burn the subs into the video directly to bypass the issue of weird sub desyncs, but i can't seem to get a grasp on that.  Actually, if i seek in the video it syncs properly, so it MUST be tied to that...
[23:23:10 CEST] <rikai> I also can not seem to burn in subs no matter what i do. Despite "ffmpeg -i punchline-intro2.mkv -vf ass="punchline-intro3.ssa" punchline-intro17.mkv" telling me "Added subtitle file: 'punchline-intro3.ssa' (36 styles, 987 events)" the final output still has no subs at all.. :/
[23:25:14 CEST] <LeoLeo> Hi ffmpeg team, may I ask you about potential bug in latest ffmpeg builds? If I try this movie  https://drive.google.com/file/d/0BygbyP4_qEiTWmNUZFprS3MtVjg/view?usp=sharing with mplayer for linux or native ffmpeg player, I receive next error each time I trying to seek forward or back: [mp3float @ 016f4a40]Header missing . Could you please help me, how to avoid this? Is this a bug of ffmpeg?
[23:36:00 CEST] <maqr> kepstin-laptop: heh, this does an interesting thing in practice
[23:36:51 CEST] <maqr> let me see if i can get logs to explain it
[23:39:24 CEST] <maqr> kepstin-laptop: it starts with the first thing in the m3u8 always... then it tries to request the quality level that it thinks is best, but it buffers pretty far ahead
[23:40:34 CEST] <maqr> kepstin-laptop: https://gist.github.com/maqr/ffb5800dba3f9e16ba8c you can see the broken pipe where it disconnected, then you can see it alternating between 64k audio only and 246k audio/video
[23:40:42 CEST] <maqr> but when it switches, the audio is continuous
[23:40:50 CEST] <maqr> i'm going to try between two video quality levels now to see if the video is also continuous
[23:41:29 CEST] <kepstin-laptop> huh, be interesting to see.
[23:46:30 CEST] <foonix> i have possible ffprobe+hevc prob, i see coded_picture_number=0 for every frame, is this unimplemented for hevc or is that a hevc feature?
[23:58:24 CEST] <maqr> kepstin-laptop: ok, so on ios8 at least, what happens is that it switches quality levels really far out, maybe 20 or 30 seconds out, it gets those files, and then it's a seemless transition in both audio and video
[23:58:33 CEST] <maqr> kepstin-laptop: it seems to have all the data it needs for the overlapping period and the switch is clean
[00:00:00 CEST] --- Thu Apr 30 2015