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

[burek]

[01:15:02 CET] <phryk> Anyone got a clue how to make video files the raspberry pi (1) can actually play? "-vcodec h264" does not seem to do the trick&
[01:22:54 CET] <JEEB> phryk: it's an awfully underpowered thing so your best bet is to just use the built-in hardware decoder and hope for the best :P
[01:23:10 CET] <JEEB> in software it's pretty much a no-go for almost anything at any decent resolution
[01:23:40 CET] <JEEB> as a hint, the original rpi actually has issues encoding AAC audio.
[01:23:48 CET] <phryk> JEEB: I know that much, I just don't know how to use ffmpeg to encode files so the rpi can properly play em
[01:24:06 CET] <phryk> I have no audio. I just want to get a gif into a format the pi can play well.^^;
[01:24:39 CET] <JEEB> the hw decoder does support H.264, but you must first make sure that your playback solution uses that :P
[01:24:57 CET] <JEEB> (of course, the hw decoder API is garbage but that's a whole separate discussion)
[01:25:00 CET] <phryk> omxplayer does that.
[01:26:06 CET] <JEEB> ok, then if I guess what the rpi's decoder chip can handle, do an encode with a recent ffmpeg with libx264 with -c:v libx264 -crf 23 -level 40
[01:26:13 CET] <JEEB> and test it out
[01:26:21 CET] <JEEB> with -an even
[01:26:25 CET] <JEEB> to not have audio :P
[01:26:35 CET] <JEEB> of course, a gif input file most likely doesn't have audio to begin with
[01:26:54 CET] <JEEB> if that doesn't play then tough luck and such
[01:27:20 CET] <JEEB> the original rpi was a thing for hacking and teaching people about computers, not a HTPC
[01:27:38 CET] <furq> it should support high at 4.1
[01:28:05 CET] <JEEB> yes, I guessed around that and thus didn't set a profile and just set level to somewhere around 4/4.1
[01:28:31 CET] <JEEB> with libx264's defaults it should end up around main profile, level 4 with my params
[01:29:13 CET] <JEEB> also since you're encoding a gif
[01:29:21 CET] <JEEB> the resolution could be something the hw decoder doesn't like
[01:29:37 CET] <JEEB> so you might end up scaling your thing and/or changing the frame rate
[01:29:42 CET] <furq> it'll be the pixel format
[01:29:50 CET] <furq> apparently gif to x264 defaults to yuv444p
[01:29:55 CET] <JEEB> right
[01:29:56 CET] <furq> phryk: -pix_fmt yuv420p
[01:29:56 CET] <JEEB> that too
[01:30:23 CET] <JEEB> just noted because some hw decoders puke at weird resolutions, like certain nvidias
[01:30:33 CET] <JEEB> or well, "weird" resolutions to be honest
[01:30:44 CET] <JEEB> which means arbitrary values that the creators didn't think of
[01:31:07 CET] <JEEB> but yes, making sure it's 4:2:0 is important
[01:31:12 CET] <JEEB> anything else is not supported by hw decoders
[01:36:39 CET] <phryk> mhh, still doesn't work for me. res should be okay, but the video is <1s long
[01:41:18 CET] <phryk> trying a longer video now
[01:47:38 CET] <phryk> -loop isn't documented in the man page :/
[01:47:52 CET] <c_14> it is (kinda)
[01:48:01 CET] <c_14> though I think it's -loop_input now
[01:48:06 CET] <phryk> no
[01:48:14 CET] <JEEB> phryk: just make sure it's yuv420p
[01:48:22 CET] <JEEB> -pix_fmt yuv420p
[01:48:42 CET] <phryk> -loop_input and loop_output are documented with a note that they're deprecated
[01:48:54 CET] <c_14> Oh, other way around -loop_input is the old one and -loop is referenced but not documented
[01:48:56 CET] <phryk> and -loop 10 does not give me a video with the input looped 10 times&
[01:49:33 CET] <furq> -loop is documented under image2, but you're not using image2
[01:49:52 CET] <phryk> No manual entry for image2
[01:50:14 CET] <furq> the gif demuxer has -ignore_loop but idk if that lets you loop a certain number of times
[01:50:27 CET] <furq> you might need to use the loop filter
[01:50:42 CET] <phryk> then what does -loop actually do?
[01:50:47 CET] <furq> for gif, nothing
[01:51:17 CET] <furq> it's a private option for the image2 demuxer, which is for most non-animated images
[01:51:46 CET] <furq> maybe -ignore_loop 10 will work? idk
[01:52:08 CET] <phryk> nope^^
[01:52:15 CET] <furq> yeah i didn't have high hopes for it
[01:52:33 CET] <furq> try -vf loop=10
[01:54:00 CET] <phryk> No such filter: 'loop' harrr
[01:54:12 CET] <furq> yeah that's new in 3.x
[01:54:50 CET] <furq> i can't see why the length would make a difference tbh
[01:55:02 CET] <furq> try using the same encoding settings with one of the test sources
[01:55:16 CET] <furq> ffmpeg -f lavfi -i testsrc=d=30 -c:v libx264 out.mkv
[01:55:51 CET] <phryk> It worked for a longer gif fine. So the short length is i think the most obvious thing to try for next.
[01:58:18 CET] <phryk> so what does -loop actually do?
[01:58:33 CET] <furq> https://www.ffmpeg.org/ffmpeg-formats.html#image2-1
[02:00:29 CET] <phryk> -loop 1 still doesn't result in an output file where the gif is repeated& :/
[02:00:45 CET] <furq> like i said, it's a private option for the image2 demuxer
[02:00:52 CET] <furq> there is no such option for the gif demuxer
[02:02:40 CET] <phryk> is there a reason why loop_[input|output] was dropped before -vf loop got in? :/
[02:03:26 CET] <furq> -loop_input was the old name for -loop iirc
[02:04:55 CET] <furq> you could maybe try -i foo.gif -loop 10 bar.gif
[02:05:17 CET] <furq> then encode bar.gif with -ignore_loop 0
[02:05:33 CET] <furq> that might fuck up the gif palette/dithering though
[02:07:37 CET] <furq> gifsicle can edit the loop count in place, that might be a better option
[02:07:42 CET] <furq> gifsicle -b -l=10 foo.gif
[02:12:03 CET] <phryk> furq: only sets the metainfo in the pics, does not actually duplicate the frames
[02:13:00 CET] <phryk> i hate software :F
[02:14:32 CET] <phryk> wait, is a non-infinite loop honored by ffmpeg?
[02:14:34 CET] <phryk> lets find out :F
[02:15:03 CET] <phryk> nnnope.
[02:15:20 CET] <furq> -ignore_loop 0 should honour the source gif's loop count
[02:15:31 CET] <furq> before -i
[02:15:39 CET] <phryk> before?
[02:15:42 CET] <furq> yes
[02:15:52 CET] <furq> options go before the file they apply to
[02:16:11 CET] <phryk> errr, not to heckle you or anything but this seems like something that should come with a big red label.
[02:16:32 CET] <phryk> the kind of thing you'd want man pages to have sth like <blink>
[02:16:39 CET] <c_14> A lot of people do seem to have problems with that.
[02:16:39 CET] <furq> shrug
[02:16:41 CET] <furq> makes sense to me
[02:16:51 CET] <c_14> Makes sense to me too.
[02:17:15 CET] <furq> not to suggest the docs are perfect or anything
[02:17:19 CET] <phryk> well it'd make sense if ffmpeg would actually take the time and bitch at you if you used parameters like that AFTER -i
[02:17:26 CET] <phryk> because -i is my VERY FIRST PARAMETER
[02:17:35 CET] <furq> i'm surprised it doesn't with that one
[02:18:04 CET] <c_14> It probably should error/warn at input parameters specified for+ output files, might be hard to do. Not sure.
[02:18:15 CET] <c_14> -+
[02:18:31 CET] <furq> i'm sure i've seen that before
[02:18:38 CET] <furq> maybe it was for a global option
[02:19:50 CET] <phryk> oh look, encoding takes way longer.
[02:20:22 CET] <furq> it is weird that there's no way to force the loop count when demuxing the gif
[02:20:45 CET] <furq> i guess ignore_loop is implemented in a way that makes that annoying to do
[02:21:59 CET] <phryk> AND THE PI FUCKING EATS IT
[02:22:06 CET] <phryk> thanks for the help :)
[02:22:21 CET] <phryk> the ducky is now one step closer to world domination. :)
[02:22:34 CET] <furq> i'm glad i don't use my pi to decode video
[02:22:54 CET] <rjp421> i want to encode gif to looped h264 flv to rtmp'
[02:23:23 CET] <rjp421> phryk, what was the cmd?
[02:49:02 CET] <phryk> rjp421: ffmpeg -ignore_loop 0 -i enteente.gif -c:v libx264 -crf 23 -level 40 -an -pix_fmt yuv420p ente.mp4
[02:49:24 CET] <phryk> enteente.gif has a loop counter of 10. if you have an infinite looping gif, it'll just infinitely encode, it seems.
[02:50:24 CET] <rjp421> nice, ty
[08:45:11 CET] <JeffATL> i need some guidance on separating audio from a video file, processing the audio externally (e.g. audacity) and joining it back in sync. i thought i had it licked with this one video that runs about 48 minutes and the sync looks great at the start but once you scroll to the end there's a noticeable gap
[08:47:34 CET] <JeffATL> here's the command i did the join with: ffmpeg  -i end_trim.mpg -i end_trim_audio_800ms_delay.mp2 -map 0:0 -map 1:0 -c:v libvpx -crf 8 -b:v 2M -vf "yadif,crop=690:470:20:0,pad=720:480:15:5"  -c:a copy  test2.mkv
[08:51:07 CET] <JeffATL> ffprobing end_trim.mpg showed "start: 0.500000" and its duration was 1300ms longer than the separated audio. so I added 800ms to the front of the audio and i thought i was fine but apparently the v and the a run at ever so slightly different speeds when separated. the drift isn't there in the source file.
[08:52:07 CET] <JeffATL> i have need to salvage a lot of the audio in these source files (some of them come off the linear audio track on tape and are therefore pretty hissy or have bad EQ)
[15:11:04 CET] <rjp421>  -vf fps=24,scale="'if(gt(a,16/9),640,-1)':'if(gt(a,16/9),-1,360)'",format=yuv420p
[15:13:03 CET] <rjp421> from https://trac.ffmpeg.org/wiki/Scaling%20(resizing)%20with%20ffmpeg trying to put a 200x200 gif in a 360p sized mp4
[15:13:41 CET] <rjp421> so it scales to fit, keeping the aspect ratio
[15:14:12 CET] <rjp421> i get a 360x360 mp4
[15:15:36 CET] <rjp421> i need 640x360
[15:42:54 CET] <Joonaa> Can I substract an audio track from another with ffmpeg? I have a song with vocals, and an instrumental (exactly the same, just no vocals), and I would like to extract the vocal track
[15:48:13 CET] <Hello71> invert instrumental and merge
[15:48:20 CET] <Hello71> *mix
[15:56:43 CET] <Joonaa> sorry, how would i invert it?
[16:01:29 CET] <mosb3rg> hey fellas, i have a cookie related question about siriusxm they use a hls system, i have finally figured out the cookie they use.. but im getting a very wierd error related to tcp:443 which i see no reference too in any playlists etc.
[16:02:27 CET] <mosb3rg> http://pastebin.com/J9wRrExA
[16:02:38 CET] <mosb3rg> heres the syntax being used, so you can see the error its here:
[16:02:58 CET] <mosb3rg> [http @ 0x7fedd40df980] No trailing CRLF found in HTTP header.0/0
[16:02:58 CET] <mosb3rg> [tcp @ 0x7fedd400c720] Connection to tcp://:443 failed (Connection refused), trying next address
[16:02:58 CET] <mosb3rg> [tcp @ 0x7fedd400c720] Connection to tcp://:443 failed: Connection refused
[16:02:58 CET] <mosb3rg> Unable to open key file http://primary.hls-streaming.production.streaming.siriusxm.com/AAC_Data/8230/HLS_8230_256k_v3/key/1
[16:02:58 CET] <mosb3rg> [http @ 0x7fedd40e0c00] No trailing CRLF found in HTTP header.
[16:03:00 CET] <mosb3rg> [http @ 0x7fedd40e0360] No trailing CRLF found in HTTP header.0/0
[16:03:14 CET] Last message repeated 1 time(s).
[16:03:14 CET] <mosb3rg> sorry about that, i tried to do a pastebin, and it stored my old clipboard.
[16:03:50 CET] <mosb3rg> http://pastebin.com/69NnK45n
[16:04:30 CET] <mosb3rg> any help would be appeciated, im very close here.. and i have seen a # of methods that handle this stuff but none of them involve ffmpeg, so im worried were missing a part of the equation.
[16:05:14 CET] <mosb3rg> https://github.com/andrew0/SiriusXM   for example uses python to login, get the SMXA token from cookie, so i noticed that was the correct cookie value.. but again i get that error, so something is missing
[16:05:57 CET] <rjp421> does your ffmpeg have --enable-openssl or --enable-gnutls
[16:06:26 CET] <mosb3rg> im using the build which comes accessible in linux mint latest.
[16:06:33 CET] <mosb3rg> is it safe to say that wont work ?
[16:07:02 CET] <mosb3rg> sec i see the compiled options when it starts let me read, so your saying thats my issue ?
[16:07:29 CET] <mosb3rg> does it start for you ? and yours is compiled like that ?
[16:07:56 CET] <mosb3rg> because im able to dump and relay all other types i have come accross using the keys and cookies
[16:09:03 CET] <mosb3rg> i do see:
[16:09:04 CET] <mosb3rg> --enable-gnutls
[16:09:51 CET] <rjp421> then i think ssl shouldnt be your problem, not sure though
[16:10:16 CET] <rjp421> hang around, someone will know
[16:10:22 CET] <mosb3rg> for sure i have to :P
[16:10:43 CET] <mosb3rg> been working on this for a couple weeks now, and read everything i can find, sometimes its a lack of terminology for the searching process.
[16:18:04 CET] <mosb3rg> oki well.. that token expires..
[16:18:38 CET] <mosb3rg> so the problem is with the sitting and waiting is i cannot provide something which just works all the time, kinda need someone whos interested in helping to be present so the token is still valid. or attempt with my login.
[16:19:01 CET] <mosb3rg> but i obviously cant just openly post my login, as i pay for it and it has my personal information etc, this channel is publically logged.
[16:19:14 CET] <mosb3rg> thats a flaw in the nature of the assistance unfortunately
[16:19:42 CET] <mosb3rg> like every single person, cannot always just post publically, but it doesnt invalidate there issue there facing or make it not important because it cannot assist directly another person. right off the bat.
[16:19:56 CET] <JEEB> yes, unfortunately this is not paid support where someone sits around for you
[16:20:01 CET] <mosb3rg> ofc not
[16:20:15 CET] <mosb3rg> i was just explaining why i cannot give somethign which constantly works
[16:20:59 CET] <mosb3rg> and how often when i explain this, im met with go figure it out for yourself, i wasnt tring to appear impatient. just that if someone wants to help i would need the login to be shared. and cant do that with tons of people because its kicks out people when someone else is on etc.
[16:22:41 CET] <mosb3rg> any how ill be around all day, if someones interested in taking a crack at this with me just say my name and ill hopefully hear the ding.
[16:35:33 CET] <mosb3rg> as i read over the python code for the server.py i got some of these details from, im noticing it mentions a static hls aes key, but isnt it unusual for the cookie not to validate the key. thats generally it, it feels like the cookie gives permission to access the files almost, then it still requires the key for decryption, is that even a possibile scenario doesnt seem to make sense.
[17:29:32 CET] <rjp421> adobe media server starter edition is free, with builtin https HLS (apache) and DRM.. might be able to setup your own for local testing
[17:31:11 CET] <JEEB> just AES-128 by itself can't really be called DRM, it's just clear key encryption
[17:31:32 CET] <rjp421> https://media.whohacked.me i havent setup hls or drm over https
[17:31:48 CET] <JEEB> you limit access to the key and content, which generally is what you need
[17:32:11 CET] <JEEB> DRM then brings the whole case of "unless you've got our black box thing in your client you can't play it"
[18:54:32 CET] <tjf> Happy new year, folks!  I have a question regarding fragmented mp4s.  I've spent the better part of the past few days reading and testing, but I am stuck.  :-(
[18:55:29 CET] <tjf> I am able to save an mp4 as fragmented by using the -movflags frag_keyframe+empty_moov and then create an HLS playlist with byteranges and it works great, no problem there.
[18:56:48 CET] <tjf> The issue I am having is that if I only want to serve a subset of the fragments, it doesn't play -- for example, let's say I have an MP4 that is fragmented into 10 fragments.  If I only want to serve a playlist that refers to fragments 3-7, it won't play -- but if I refer to fragments 1-7, it does.
[18:57:04 CET] <tjf> There seems to be some reliance on the first fragment by the player (Safari)
[18:57:18 CET] <tjf> However, Apple's test FMP4 -- I can start it at any fragment.
[18:58:27 CET] <kerio> superior fruit technology
[18:58:58 CET] <tjf> I did some looking at the files, and one thing I notice is that on the Good (Apple) file, the 'tfhd' box does not contain any sample flags (is set to 00 00 00 00) while on the Bad (ffmpeg mux'ed) file, the sample flags are set to (01 01 00 00) -- from the spec, this appears to indicate 'sample_depends_on' and 'sample_is_nonsync_sample'
[18:59:30 CET] <tjf> yea, I know.. this would be easier if my fruity Safari browser would give me some sort of error log indicating what is not correct, in its opinion ;-)
[18:59:59 CET] <c_14> -movflags omit_tfhd_offset ?
[19:00:38 CET] <c_14> or the other one default_base_moof
[19:00:38 CET] <tjf> so, I am running default_base_moof which, from what I can see in movenc.c seems to do the same thing, while also setting (or unsetting) the appropriate flag on the tfhd box -- but yes, I've tried that as well with no change.
[19:00:49 CET] <JEEB> I would guess the fragment you're aiming at a) either isn't a sync sample or b) doesn't have the parameter sets
[19:01:06 CET] <JEEB> you have to set it to duplicate parameter sets
[19:01:14 CET] <JEEB> which would explain 1-7 working :P
[19:01:23 CET] <tjf> is that an option I can toggle on the CLI?
[19:01:26 CET] <JEEB> yes
[19:01:31 CET] <JEEB> I think libx264 had it
[19:01:36 CET] <JEEB> if not the movenc muxer
[19:02:03 CET] <tjf> ok, hopefully the muxer as this is already encoded by a security camera of mine -- trying to avoid the re-encode
[19:02:06 CET] <JEEB> also do you have min/max fragment lengths set?
[19:02:24 CET] <tjf> I am fragmenting on the keyframe, so it is fragmenting every 2 seconds
[19:02:27 CET] <JEEB> because those actually override frag_keyframe
[19:02:44 CET] <tjf> frag_keyframe+empty_moov+default_base_moof is what I'm setting
[19:02:59 CET] <JEEB> ok, and no separate min/max fragment length?
[19:03:02 CET] <tjf> no
[19:03:03 CET] <JEEB> it's not a movflags param
[19:03:04 CET] <JEEB> ok
[19:03:12 CET] <JEEB> not sure if the movenc muxer has the flag :P
[19:03:35 CET] <JEEB> I've always used the movenc muxer with fragments so that something else handles the duplication of parameter sets
[19:04:34 CET] <tjf> ok.. so 'duplicate parameter sets' gives me a little more to go on -- I think there's a movflags option for min frag size too
[19:04:44 CET] <JEEB> don't set that
[19:04:50 CET] <JEEB> those specifically can make things go wrong
[19:04:50 CET] <tjf> oh, ok
[19:04:55 CET] <JEEB> with frag_keyframe
[19:05:02 CET] <tjf> k..
[19:05:25 CET] <JEEB> as in, those fragment min/max duration flags actually override the frag_keyframe flag :P
[19:05:33 CET] <tjf> yea, I'm seeing that in the docs/source now
[19:06:04 CET] <JEEB> anyways, not seeing an option for duplicating parameter sets (or "extradata" as it's often noted)
[19:06:21 CET] <tjf> yea, not seeing anything either :-(
[19:06:47 CET] <JEEB> also are you sure those pictures that are coming from your encoder are actual random access points?
[19:06:58 CET] <JEEB> if your first sample in a fragment is not a sync sample
[19:07:38 CET] <JEEB> you can actually check the output of the movenc encoder with regards to samples with L-SMASH's boxdumper, it creates nice text file outputs of mov-style containers with the --box switch
[19:07:48 CET] <tjf> I'm not sure, unfortunately -- I only know that my cam is running at 10fps with a keyframe every 20 frames --
[19:07:56 CET] <JEEB> https://github.com/l-smash/l-smash
[19:07:58 CET] <tjf> i see
[19:08:05 CET] <JEEB> yeah, but is the keyframe IDR or just I
[19:08:11 CET] <tjf> ok, I'll give that a shot to see what I can find
[19:08:12 CET] <JEEB> IDR is a random access point
[19:08:20 CET] <tjf> good question -- would ffprobe be able to tell me that?
[19:08:25 CET] <tjf> with -show_frames ?
[19:08:32 CET] <JEEB> I think on some level yes
[19:08:38 CET] <tjf> k, give me a sec, let me see
[19:08:44 CET] <JEEB> since it flags IDRs and open gop sei + I as "keyframes"
[19:09:25 CET] <JEEB> but then it'd be weird for the initial sample not to be a sync sample if I recall correctly
[19:09:34 CET] <JEEB> although fragments don't have to begin with a sync sample any moe
[19:09:35 CET] <JEEB> *more
[19:10:16 CET] <tjf> yea, every 20th frame appears to have key_frame=1 on the ffprobe output
[19:10:44 CET] <JEEB> which makes sense why fragmentation on "keyframes" works
[19:10:57 CET] <JEEB> anyways, check your fragmented file with boxdumper --box
[19:11:04 CET] <tjf> k, going to give that a shot
[19:11:08 CET] <tjf> thanks for the tip! :-)
[19:11:14 CET] <JEEB> recommend either piping to less or to a file
[19:11:18 CET] <tjf> I'll prob be back with more info shortly
[19:11:35 CET] <JEEB> because as you'd guess a text-based representation of the file is rather verbose :P
[19:12:10 CET] <tjf> of course ;-)
[19:12:11 CET] <JEEB> btw, it'd be interesting to know if your camera outputs the parameter sets
[19:12:18 CET] <JEEB> after the initial connection
[19:12:28 CET] <JEEB> as in, does it duplicate them by itself or not
[19:13:02 CET] <JEEB> one way to test is to just use dd or something to cut the first fragment or so off
[19:13:11 CET] <JEEB> and see if, say, ffprobe or mpv can play it afterwards
[19:14:26 CET] <tjf> k
[19:14:38 CET] <JEEB> you'll see the offsets in boxdumper's output as well
[19:14:54 CET] <tjf> k, just got boxdumper installed, let's see what i find
[19:16:07 CET] <JEEB> I should probably finish up my patch for L-SMASH/boxdumper for smooth streaming timestamp boxes
[19:16:30 CET] <tjf> ok, so I've got the boxdumper output -- what am I looking at, the moof boxes?
[19:16:45 CET] <JEEB> there should be the sample lists with their flags
[19:17:08 CET] <tjf> in the trun box, I assume?
[19:17:20 CET] <JEEB> can't remember the names unfortunately :D
[19:17:35 CET] <JEEB> but probably
[19:18:15 CET] <tjf> k, well trun has the list of samples for the fragment, it appears --
[19:18:17 CET] <tjf> let's see here..
[19:19:03 CET] <tjf> ok, so first fragment --
[19:19:09 CET] <JEEB> also did you use separate_moof, don't remember?
[19:19:20 CET] <JEEB> which writes separate fragments for tracks
[19:19:26 CET] <tjf> I didn't, but this cam is video only -- 1 track
[19:19:33 CET] <JEEB> ok
[19:19:39 CET] <JEEB> then each fragment should start with a sync sample
[19:19:47 CET] <JEEB> I think if I got my ISOBMFF words right
[19:19:56 CET] <tjf> so, first fragment -- default_sample_flags = 0x01010000
[19:20:13 CET] <tjf> under that, it says dependent and non-sync sample
[19:20:21 CET] <JEEB> ok
[19:20:32 CET] <JEEB> so your camera starts feeding you non-sync samples I guess
[19:20:49 CET] <tjf> it's the same on all the fragments, actually
[19:21:06 CET] <JEEB> also I think there was something about random access
[19:21:14 CET] <JEEB> let me run boxdumper here locally
[19:21:57 CET] <tjf> for comparison, the apple test file has default_sample_flags = 0x00000000
[19:22:05 CET] <tjf> (sync sample) :-(
[19:22:21 CET] <tjf> so, is this a mux thing or an encoder thing?
[19:22:58 CET] <tjf> this is in the tfhd box, btw
[19:23:11 CET] <JEEB> tjf: keep looking at the following segments
[19:23:32 CET] <JEEB> because it could be that your input stream isn't beginning with an IDR or open gop sei+I
[19:23:50 CET] <tjf> k, let me check all the tfhd boxes and see
[19:24:00 CET] <tjf> or, wait a sec..
[19:24:18 CET] <JEEB> also I did remember there being a random access point flag and I'm trying to make sure if that is the sync sample flag
[19:24:35 CET] <tjf> in the trun box (which is a sibling of tfhd and actually contains the samples) .. I see:
[19:24:36 CET] <tjf>                 first_sample_flags = 0x02000000
[19:24:45 CET] <tjf> independent, sync sample
[19:24:50 CET] <JEEB> yup, that sounds better
[19:25:07 CET] <tjf> and every fragment has that
[19:25:10 CET] <tjf> not just the first
[19:25:29 CET] <JEEB> yup
[19:25:52 CET] <JEEB> do you have just one stsd btw?
[19:25:54 CET] <tjf> so that's good, right?  (for what I'm trying to accomplish, anyway -- pardon my ignorance) :-D
[19:26:06 CET] <tjf> let me see
[19:26:22 CET] <tjf> yes, only one stsd in the moov
[19:26:48 CET] <JEEB> that's where the parameter sets are kept
[19:26:52 CET] <JEEB> under avcc
[19:26:54 CET] <JEEB> for AVC
[19:27:02 CET] <JEEB> they can also be in-band of course
[19:27:21 CET] <JEEB> (not sure -c copy mechanics but I would guess it just doesn't rip them out)
[19:27:27 CET] <tjf> k..
[19:28:11 CET] <JEEB> but yeah, having the sync sample flag there sounds good enough. now you can look at the right spot to cut and cut off the first segment and see if that plays in lavf-based solutions
[19:28:15 CET] <JEEB> like ffprobe or mpv
[19:29:22 CET] <tjf> ok, so.. I should snip a fragment out of the main file and try playing that with mpv?
[19:29:34 CET] <tjf> fragment 1 or ... greater than 1?
[19:29:54 CET] <tjf> I assume I'd need the ftyp and moov boxes as well, right?
[19:30:31 CET] <tjf> so if I'm understanding correctly, I need to cut the first fragment out and try playing it?
[19:30:42 CET] <tjf> (playing the file without the first fragment in it, that is)
[19:31:08 CET] <JEEB> yes, so that you definitely don't hav ethat stsd
[19:31:42 CET] <tjf> ok, so, the stsd is in the moov box -- not the moof...
[19:32:04 CET] <JEEB> does it actually contain the AVCc there?
[19:32:42 CET] <JEEB> I would guess so since even empty_moov should "describe the tracks"
[19:32:48 CET] <tjf> stsd in moov has avc1 box that contains avcC box
[19:33:10 CET] <tjf> and my box dump only has one avcC box in it
[19:33:18 CET] <JEEB> yea, that makes sense
[19:34:01 CET] <JEEB> anyways, in DASH this isn't an issue because the stsd-containing fragment gets written separately and the manifest says that the initialization segment is elsewhere (or pointing towards the beginning of the file if a single file with offsets)
[19:34:31 CET] <tjf> yea, so HLS does something similar -- it has a byterange for the init segment which contains the ftyp and moov (and therefore stsd)
[19:34:46 CET] <JEEB> ok, then it's weird that it doesn't wokr
[19:34:48 CET] <JEEB> *work
[19:35:06 CET] <tjf> ok, so I'm going to try removing the first fragment from the file and playing it with mpv and see what I get
[19:35:52 CET] <tjf> to be clear, I'm going to take my file that is currently [ftyp,moov,frag1,frag2,frag3...] and alter it to [ftyp,moov,frag2,frag3...] and try to play it.  That's what you're suggesting, correct?
[19:35:53 CET] <JEEB> esp. if all things begin with a sync sample
[19:36:23 CET] <JEEB> tjf: do you have that init segment for the apple player too?
[19:36:28 CET] <JEEB> if yes, then that
[19:36:28 CET] <tjf> yep
[19:36:31 CET] <JEEB> ok
[19:36:38 CET] <JEEB> and then it should work
[19:36:54 CET] <tjf> ok, I will report back shortly.  Thanks a ton for your help!
[19:36:55 CET] <JEEB> I would have thought HLS doesn't have that and you'd have to duplicate everything
[19:37:21 CET] <JEEB> (just like with MPEG-TS)
[19:38:14 CET] <tjf> yea.. if you're curious, check out sec 3.3 here: https://tools.ietf.org/html/draft-pantos-http-live-streaming-20
[19:38:26 CET] <tjf> the #EXT-X-MAP tag is where you specify the byterange of it
[19:38:39 CET] <tjf> bbiaf
[19:42:53 CET] <rjp421> JEEB, im trying to put a 200x200 gif in a 360p sized mp4 so it scales to fit, keeping the aspect ratio, but i get a 360x360 mp4... i need 640x360 :(   https://trac.ffmpeg.org/wiki/Scaling%20(resizing)%20with%20ffmpeg i tried mangling one of the examples to:  -vf fps=24,scale="'if(gt(a,16/9),640,-1)':'if(gt(a,16/9),-1,360)'",format=yuv420p
[19:44:23 CET] <JEEB> tjf: you could compare it to the dash encoder's -single_file flag
[19:44:45 CET] <tjf> JEEB: will give that a shot once I'm done with dd over here :-D
[19:44:47 CET] <JEEB> (you need to set the output file to a .mpd manifest but it will then write the segments)
[19:45:05 CET] <JEEB> that uses the movenc muxer, basically
[19:45:24 CET] <JEEB> and that is supposed to write the kind of fragmented mp4 that DASH expects
[20:05:00 CET] <tjf> JEEB: good news -- basically, I'm a moron :-D
[20:05:22 CET] <JEEB> E_NOT_SURPRISING
[20:05:25 CET] <tjf> lol
[20:05:31 CET] <tjf> so, here's what I was doing wrong
[20:05:37 CET] <JEEB> because I just asked someone who had done the fragmented mp4 in HLS thing
[20:05:46 CET] <JEEB> and he said that other than the playlist it should be possible :P
[20:05:54 CET] <tjf> I created my manifest _before_ I began using the default_base_moof
[20:06:07 CET] <tjf> when I began using that option, my byte ranges all shifted a bit
[20:06:11 CET] <tjf> but I didn't update my manifest
[20:06:23 CET] <JEEB> right
[20:06:28 CET] <JEEB> so the offsets were all over the place
[20:06:40 CET] <tjf> so -- I apologize for wasting your time, but huge thanks for taking the time to assist and show me boxdumper -- super handy tool
[20:07:23 CET] <JEEB> might be interesting to add support for fragmented isobmff hls
[20:07:27 CET] <JEEB> into libavformat
[20:07:44 CET] <JEEB> or include it in dashenc
[20:07:56 CET] <tjf> yea, it's fairly recently supported by Apple, announced earlier this year I guess..
[20:08:08 CET] <tjf> prior to that was all mpegts
[20:08:17 CET] <JEEB> yes
[20:08:27 CET] <JEEB> that way you can actually share video data between HLS and DASH
[20:08:37 CET] <tjf> That seems like a patch I'd be able to whip up as most of the heavy lifting is already done ;-)
[20:08:50 CET] <tjf> s/most/all :-D
[20:09:19 CET] <KCat156> I'm trying to play an mpjg stream by using "ffplay http://201.166.63.44/axis-cgi/mjpg/video.cgi", but it gets stuck after a few seconds
[20:09:34 CET] <tjf> anyways, have a great evening and thanks again!
[20:09:39 CET] <JEEB> np
[22:24:42 CET] <rhagu> Hi, I have a directory full of mkvs and I know that some of the got corrupted due to a disk failure. I have a lot of time and my server can decode them one by one. Is there a way to use ffmpeg to look for missing parts in mkvs, but diregard output like "warning unknown framerate"?
[22:25:10 CET] <JEEB> `ffmpeg -i input -f null -` will decode
[22:26:29 CET] <rhagu> JEEB does it filter errors about missing parts from warnings?
[22:26:47 CET] <rhagu> I would like to end up with a list of corrupt mkvs afterward
[22:26:59 CET] <JEEB> no, that's just the basic thing. then you can separately set the mode to explode :P
[22:27:13 CET] <JEEB> which will exit if the decoder thinks stuff's broken enough
[22:29:03 CET] <rhagu> JEEB "ffmpeg -v explode -i input -f null -"?
[22:30:31 CET] <JEEB> not sure if explode is a verbosity option :P
[22:30:42 CET] <JEEB> probably you want to see ffmpeg-all.html on the ffmpeg site
[22:30:46 CET] <JEEB> and ctrl+f for it
[22:33:51 CET] <rhagu> JEEB mhm, I guess missing parts of a video should turn up with "aggressive", right?
[22:36:01 CET] <rjp421> i patch but then still leave default configs
[22:36:21 CET] <rjp421> wrong channel
[00:00:00 CET] --- Mon Jan  2 2017