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

[burek]

[01:04:29 CEST] <tmm1> is there a way to disable a CONFIG_EXTRA option via the cmd line
[01:16:29 CEST] <jamrial> tmm1: no
[05:30:56 CEST] <jya> wondering why the difference in the default scaling list used in fffmpeg (https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264_ps.c#L43) vs what's in the spec stable (and used by chrome https://cs.chromium.org/chromium/src/media/filters/h264_parser.cc?q=kDefault4x4Intra&sq=package:chromium&l=521 , or mesa:
[05:30:56 CEST] <jya> https://fossies.org/linux/mesa/src/gallium/state_trackers/omx/vid_dec_h264.c#150)
[05:31:14 CEST] <jya> for h264 that is...
[06:04:12 CEST] <philipl> Does anyone know how android slow-motion video metadata is encoded? The files report themselves as being 30fps and if played at 30fps, play at the slow motion speed, but the editor lets you mark which section you want slow and it plays the rest in realtime. Is it even encoded in the file?
[06:09:32 CEST] <rcombs> philipl: I have the same question about iOS's similar feature
[06:09:52 CEST] <rcombs> iirc some people talked about VFR wrt that? but dunno any details
[06:10:38 CEST] <philipl> https://developer.android.com/reference/android/media/MediaFormat.html
[06:10:42 CEST] <philipl> They talk about temporal layering
[06:11:02 CEST] <philipl> and there's a com.android.video.temporal_layers_count property in the container metadata
[06:11:18 CEST] <philipl> so perhaps this (where I don't really know what 'this' is) is it
[06:11:50 CEST] <philipl> android certainly isn't VFR. The file is constant rate and the audio is also slowed down to match the video
[06:11:51 CEST] <rcombs> is it BMFF?
[06:12:04 CEST] <philipl> yes
[06:12:46 CEST] <rcombs> maybe look around for unusual atoms in boxdumper/mp4info/such
[06:12:55 CEST] <rcombs> if there's nothing else interesting in metadata
[06:14:57 CEST] <philipl> Will poke around.
[06:23:57 CEST] <philipl> I have an ios slow mo file here too. They seem to do the opposite. The base metadata and timestamps are realtime
[06:24:00 CEST] <philipl> So it's a 120fps file
[06:32:02 CEST] <philipl> There are some unknown boxes.
[07:01:18 CEST] <philipl> rcombs: I think they use h.264 svc. The base layer is the slow motion and then presumably, there are other layers that indicate the realtime sections.
[07:01:29 CEST] <rcombs> iOS or Android?
[07:01:34 CEST] <philipl> android.
[07:01:36 CEST] <rcombs> also, ew, SVC
[07:01:53 CEST] <philipl> ios could be the same, with a the realtime as the base layer.
[07:02:05 CEST] <rcombs> also, wait, what? That doesn't sound like a sane use of SVC
[07:02:10 CEST] <rcombs> just to encode metadata?
[07:02:32 CEST] <rcombs> they both have the base layer encode every frame, right?
[07:02:37 CEST] <rcombs> and just have timestamps differ
[07:02:50 CEST] <philipl> i agree it's weird, but it's not in the container metadata
[07:03:08 CEST] <philipl> and they keep calling them temporal layers which is svc jargon.
[07:03:30 CEST] <philipl> yes. in both cases, the base layer has all frames.
[07:07:22 CEST] <philipl> We don't attempt to parse any svc metadata do we?
[07:29:10 CEST] <rcombs> philipl: afaik no
[07:29:44 CEST] <rcombs> (not saying you're wrong, just saying it's dumb, which isn't unusual for android media things)
[07:30:30 CEST] <rcombs> I don't know enough about SVC to say how you would find out any more
[07:32:33 CEST] <rcombs> I guess it could make sense if they used it to skip decoding frames they don't need? Would they duplicate frames at different rates for that (SVC stuff maybe, I dunno how that works?), or do they have really funky-looking GoPs where every 4-or-so frames suspiciously doesn't reference any of the previous 3?
[08:50:16 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:d13740f3a207: lavc/parser: export field order if not already set
[08:50:16 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:f271a9bd991b: lavc/h264_parser: export field order in more cases
[08:50:17 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:ba53504e57b6: lavc/utils: avcodec_string: dump field order when known
[08:50:18 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:54350f06e117: ffprobe: report field order for video streams
[08:50:19 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:8a24e03684ca: MAINTAINERS: add myself for audiotoolbox
[10:20:15 CEST] <nevcairiel> jya: looks to me like one of those is in zigzag order, probably ffmpegs
[10:30:10 CEST] <mateo`> philipl: the slow-mo media recorded on android are reported at 30fps but ... you'll find the following metadata in the mp4 container: com.android.capture.fps
[10:30:57 CEST] <mateo`> which reports the correct fps
[10:45:59 CEST] <rcombs> mateo`: the question is how the whole "set some parts to slow and other parts to full-speed" thing works
[10:50:45 CEST] <nevcairiel> isnt SVC spatial not temporal
[10:51:28 CEST] <nevcairiel> guess its both
[10:51:50 CEST] <nevcairiel> (Temporal scalability is already enabled by H.264/MPEG-4 AVC. SVC has only provided supplemental enhancement information to improve its usage.)
[10:51:53 CEST] <nevcairiel> so much for that
[10:51:53 CEST] <nevcairiel> :D
[10:52:29 CEST] <jya> nevcairiel: oh that makes sense.. thank you !
[10:52:52 CEST] <jya> doh, how didn't I figure that one out 
[10:55:40 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:a246fef16338: lavf/mux: add avformat_init_output
[10:55:41 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:c7cd6ad8509c: lavf/segment: add deinit function
[10:55:42 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:45f5c5573203: lavf/segment: fix writing separate header with auto BSF
[10:55:43 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:e83d5d7e58ff: lavf/movenc: add deinit function
[10:55:44 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:c972a28fc3de: lavf/dashenc: add deinit function
[10:55:45 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:42cb050a0502: lavf/movenc+dashenc: add automatic bitstream filtering
[10:55:46 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:d99d7cbdfc70: lavf/rawenc: add automatic bitstream filtering for H264+HEVC
[10:55:47 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:a6da754ef9a7: fate/h264: make mp4toannexb test use auto-BSF
[10:55:48 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:ed4e081a362d: fate/aac: add automatic bsf test
[10:55:49 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:3b3f979894a0: fate/hevc: add automatic bsf test
[10:56:22 CEST] <nevcairiel> \o/
[10:56:32 CEST] <rcombs> it's one of those days
[10:58:04 CEST] <nevcairiel> probably a ticket or two which can be closed now?
[10:58:42 CEST] <rcombs> oh, good point
[10:59:25 CEST] <rcombs> but I can't be arsed to find them
[10:59:29 CEST] <nevcairiel> hehe
[10:59:32 CEST] <rcombs> it's damn difficult to find trac issues relevant to a topic
[10:59:35 CEST] <nevcairiel> they'll turn up
[10:59:49 CEST] <rcombs> because everyone posts their full ffmpeg output
[10:59:56 CEST] <rcombs> and it includes a bunch of names of unrelated shit
[11:00:23 CEST] <nevcairiel> the search also finds closed tickets, which isnt very helpful
[11:00:32 CEST] <rcombs> wtb something to get banner output excluded from search
[11:02:02 CEST] <rcombs> nevcairiel: hey, happen to have some MKV files with header stripping laying around?
[11:02:17 CEST] <rcombs> I need to test to make sure Roku really did fix their shit
[11:02:23 CEST] <nevcairiel> cant you just create one
[11:02:46 CEST] <nevcairiel> take for example dts, has a fixed sync start word, and shove it into mkv with the option turned on
[11:02:49 CEST] <rcombs> probably, but I tend to prefer existing samples to make sure I don't fuck it up
[11:03:04 CEST] <rcombs> allegedly, at some point it was fixed, but only for some specific codecs
[11:03:13 CEST] <rcombs> or, like, for audio but not for video or something
[11:03:13 CEST] <nevcairiel> that sounds odd
[11:03:17 CEST] <rcombs> (how do you fuck up that badly)
[11:03:32 CEST] <nevcairiel> you would probablky have to go out of your way to fix it only for one type
[11:03:36 CEST] <nevcairiel> but you know, hardware makers
[11:03:37 CEST] <rcombs> right?
[11:03:53 CEST] <rcombs> thus my skepticism
[11:04:12 CEST] <nevcairiel> for video the best you can probably get is a h264 stream with one 0 stripped from the 4-byte length code =p
[11:05:01 CEST] <rcombs> you could just set the length-size field to 3 bytes :3
[11:05:09 CEST] <nevcairiel> thats not valid
[11:05:13 CEST] <rcombs> oh really?
[11:05:21 CEST] <wm4> yay for matroska saving 1 byte per packet
[11:05:21 CEST] <rcombs> why is the field even there, then
[11:05:24 CEST] <nevcairiel> (some files do it though, but officially out of spec)
[11:05:31 CEST] <nevcairiel> it can be 2, technically
[11:05:44 CEST] <nevcairiel> although for HD video 2 is probably too small
[11:05:48 CEST] <rcombs> yeah
[11:05:52 CEST] <rcombs> whose spec, anyway
[11:06:07 CEST] <nevcairiel> its the mov/mp4 spec thing
[11:06:07 CEST] <rcombs> isn't the MP4 bitstream format not part of MPEG-4 Part 10
[11:06:13 CEST] <rcombs> which one
[11:06:24 CEST] <rcombs> (aren't there like 12)
[11:06:24 CEST] <nevcairiel> let me find it
[11:06:30 CEST] <rcombs> nah don't bother
[11:06:35 CEST] <nevcairiel> ISO_IEC_14496-15
[11:06:42 CEST] <rcombs> I'm just being annoyed at the state of multimedia standards
[11:06:42 CEST] <nevcairiel> Carriage of NAL unit structured video in
[11:06:42 CEST] <nevcairiel> the ISO Base Media File Format
[11:07:37 CEST] <rcombs> y'know I once had to recover a .mp4 from a device that had shutdown midway through writing the sample table
[11:07:52 CEST] <nevcairiel> The value of this field shall be one of 0, 1, or 3 corresponding to a
[11:07:52 CEST] <nevcairiel> length encoded with 1, 2, or 4 bytes, respectively.
[11:07:58 CEST] <rcombs> ended up writing a script to split packets based on AUDs
[11:08:00 CEST] <nevcairiel> 3 isnt speced
[11:08:04 CEST] <nevcairiel> although i have seen files use it
[11:08:06 CEST] <nevcairiel> so much for that
[11:08:06 CEST] <nevcairiel> :D
[11:08:14 CEST] <rcombs> whose idea was it for cameras to record in a format like this shit
[11:08:20 CEST] <nevcairiel> rcombs: lucky they put AUDs in mp4
[11:08:28 CEST] <rcombs> lol single giant monolithic header
[11:08:57 CEST] <rcombs> hope you never run out of battery
[11:10:20 CEST] <nevcairiel> and yeah header stripping is mostly useless, the savings are usually extremely minimal
[11:10:33 CEST] <nevcairiel> and requires two pass processing to even find a common header
[11:10:54 CEST] <rcombs> does the header have to be common to literally all packets
[11:10:55 CEST] <nevcairiel> mosu just forced it in mkvmerge for a while to get broken hardware people to fix their shit =p
[11:10:58 CEST] <nevcairiel> yes
[11:11:05 CEST] <rcombs> wew
[11:11:17 CEST] <wm4> indeed, that's one good thing mkv has over mp4: it's actually streamable
[11:11:32 CEST] <rcombs> lol fragmented MP4
[11:11:41 CEST] <wm4> I'll never understand how mp4 got such widespread use in streaming
[11:11:54 CEST] <wm4> or why things like fragmented mp4 have to exist
[11:12:13 CEST] <nevcairiel> i was meaning to try to get $works streaming module to output streaming mkv, but I havent found a real usecase yet that interested me
[11:12:20 CEST] <wm4> even hls seems reasonable in comparison (...ok maybe not)
[11:12:45 CEST] <nevcairiel> we have way too many streaming formats anyway
[11:12:54 CEST] <rcombs> nevcairiel: I use it for streaming to Chrome and mpv
[11:12:56 CEST] <nevcairiel> hls, hds, dash, probably fogetting some more arcane ones
[11:12:56 CEST] <rcombs> and Roku
[11:13:12 CEST] <rcombs> it works better than HLS on some stupid devices
[11:13:30 CEST] <rcombs> because they have a tendency to try to buffer entire MPEGTS segments in memory instead of downloading them progressively
[11:13:37 CEST] <nevcairiel> we currently do hls or plain mpegts streams, which works for android and some other things, but i may remember someone complaining that roku fails
[11:13:44 CEST] <rcombs> whereas if you give them a monolithic MKV stream, they handle it fine
[11:14:01 CEST] <rcombs> yeah, Roku falls over on HLS segments larger than some particular threshold
[11:14:10 CEST] <wm4> <rcombs> because they have a tendency to try to buffer entire MPEGTS segments in memory instead of downloading them progressively <- don't you have to do this
[11:14:12 CEST] <rcombs> just freezes up and sits there
[11:14:16 CEST] <wm4> to not get playback dropouts
[11:14:19 CEST] <rcombs> wm4: no?
[11:14:22 CEST] <rcombs> and lavf doesn't
[11:14:26 CEST] <wm4> lol
[11:14:38 CEST] <nevcairiel> well it depends
[11:14:43 CEST] <wm4> my main motivation to add a buffered packet queue to mpv was because of lavf's hls
[11:14:50 CEST] <nevcairiel> buffering can help if you have varying connection stability
[11:14:58 CEST] <rcombs> well yes buffering is good
[11:15:07 CEST] <nevcairiel> but  you dont have to buffer entire segments if that exceeds your memory availability
[11:15:08 CEST] <wm4> so effectively mpv will buffer at least 1 hls fragment or so in memory so lavf starts downloading the next one
[11:15:09 CEST] <rcombs> but there's no reason you have to buffer by segment
[11:15:31 CEST] <wm4> because recreating the tcp connection and such increases latency by "too much"
[11:15:40 CEST] <nevcairiel> these rokus are cheap-ass hardware devices, they dont exactly come with plenty memory
[11:15:52 CEST] <wm4> of course ideally lavf would just start buffering fragments asynchronously
[11:16:13 CEST] <rcombs> wait, they still open a new TCP socket per request?
[11:16:14 CEST] <nevcairiel> cant you do keep-alive and use the same http connection for hls
[11:16:16 CEST] <rcombs> wat?
[11:16:27 CEST] <wm4> dunno, but fairly sure lavf can't do this
[11:16:27 CEST] <rcombs> lavf HTTP even supports pipelining
[11:16:32 CEST] <wm4> oh it does?
[11:16:39 CEST] <rcombs> yeah, dunno if HLS uses it though
[11:16:41 CEST] <rcombs> you have to try
[11:16:50 CEST] <rcombs> it's not automatic or anything
[11:17:01 CEST] <nevcairiel> i'm not a big fan of any streaming support in lavf, it seems all a bit wonky
[11:17:14 CEST] <nevcairiel> i expose some but when someone reports a problem i usually just tell them that i dont care
[11:17:29 CEST] <nevcairiel> (not to mention that testing streaming problems is often impossible)
[11:17:32 CEST] <rcombs> HTTP/1.1 lets you send the next request before you finish receiving the response to the first
[11:17:44 CEST] <rcombs> but I dunno if lavf supports that
[11:17:49 CEST] <nevcairiel> how would that work
[11:17:59 CEST] <rcombs> and it'd be at least non-trivial to handle in hlsdec.c
[11:18:04 CEST] <rcombs> nevcairiel: literally just that
[11:18:17 CEST] <wm4> yeah, lavf is generally wonky for anything
[11:18:19 CEST] <rcombs> you send the next request before you've finished reading the response to the current one
[11:18:30 CEST] <nevcairiel> typical pipelining is just to request a new file once the previous finishes, not while its still running o.o
[11:18:54 CEST] <rcombs> sure, but in e.g. HLS, you can send the next one early
[11:19:04 CEST] <rcombs> so you don't have to wait an RTT to start getting additional packets
[11:19:10 CEST] <nevcairiel> i guess
[11:19:19 CEST] <nevcairiel> but without re-opening the connection the overhead is probably fine
[11:19:27 CEST] <rcombs> yeah, that's the bigger thing
[11:19:31 CEST] <nevcairiel> now if you do a new connection every time
[11:19:33 CEST] <nevcairiel> thats painful
[11:19:52 CEST] <rcombs> esp. with TLS
[11:20:04 CEST] <rcombs> though that gets cheaper with 1.3
[11:20:21 CEST] <nevcairiel> 10 years until widespread adoption? =p
[11:20:50 CEST] <rcombs> nah, new TLS stuff tends to get decent adoption reasonably quickly these days
[11:20:57 CEST] <rcombs> I mean, just look at how quickly HTTP/2 caught on
[11:21:11 CEST] <nevcairiel> with all the servers running old-ass distributions?
[11:21:12 CEST] <nevcairiel> we'll see
[11:21:43 CEST] <wm4> http 2 gets any use?
[11:21:44 CEST] <rcombs> guess it depends what you mean by widespread
[11:21:46 CEST] <rcombs> wm4: sure
[11:22:49 CEST] <rcombs> https://w3techs.com/technologies/details/ce-http2/all/all
[11:22:57 CEST] <rcombs> over 10% now
[11:22:59 CEST] <nevcairiel> google uses all sorts of these things to just get 1% efficiency, like QUIC, but not sure i consider google and some other big names using it wide-spread :D
[11:23:15 CEST] <rcombs> and all the major CDNs do it
[11:23:37 CEST] <rcombs> including cloudflare
[11:23:52 CEST] <nevcairiel> guess that automatically makes it available in many places
[11:24:21 CEST] <nevcairiel> but who knows how much its worth if the backend behind cloudflare only talks http1
[11:24:41 CEST] <rcombs> plenty if it's static resources
[11:25:43 CEST] <rcombs> and client support is there
[11:40:06 CEST] <jya> nevcairiel: looking at various h264 implementation, that would make them all wrong then, or just ffmpeg
[11:41:10 CEST] <jya> like the MESA/OMX (author is AMD), when no table is defined, they simply memcpy the default table (non zigzag) 
[11:41:14 CEST] <jya> same with chrome
[11:41:35 CEST] <jya> the zigzag is only ever applied from the data read from the sps/pps
[11:42:17 CEST] <nevcairiel> you have to apply zigzag somewhere
[11:42:26 CEST] <nevcairiel> either you pre-zigzag the table or you do it later
[11:42:42 CEST] <nevcairiel> and when dealing with hardware, ffmpeg has to un-zigzag the tables before giving it to the hardware
[11:42:49 CEST] <jya> nevcairiel: I'm fairly certain they never apply the zigzag on the default scale values
[11:43:53 CEST] <nevcairiel> well it works,  doesnt it
[11:44:39 CEST] <jya> that the MESA code: https://fossies.org/linux/mesa/src/gallium/state_trackers/omx/vid_dec_h264.c#150, just plain memcpy on the default scales. 
[11:44:54 CEST] <jya> well, I'm yet to find a video getting into that case anyway :)
[11:45:07 CEST] <jya> so maybe that's why it works !
[11:46:20 CEST] <nevcairiel> it mostly depends on the expectation of the API, does it want these zigzaged or plain, hardware probably prefers plain most of the time
[11:47:56 CEST] <jya> nevcairiel: is the scale tables zigzagged?
[11:48:02 CEST] <jya> in the SPS that is
[11:48:30 CEST] <nevcairiel> in the bitstream? dont think so
[11:50:45 CEST] <jya> hmmm... so looking at the dxva2_h264.c , it uses the value as-is, so I'm guessing it takes zigzag stuff
[11:51:07 CEST] <nevcairiel> actually it unzigzags it
[11:51:20 CEST] <nevcairiel> qm->bScalingLists4x4[i][j] = pps->scaling_matrix4[i][ff_zigzag_scan[j]];
[11:52:12 CEST] <nevcairiel> (note that there is a work-around mode above because some old hardware expected the wrong stuff)
[11:52:33 CEST] <jya> oh...
[11:52:48 CEST] <jkqxz> Mesa codec stuff is meant to be a thin shim layer for access to the hardware.  The OMX implementation happens to be large and complex because OMX specifies a whole-stream decoder, and so they have to reimplement all of the parsing there.  Looking at the VDPAU or VAAPI implementations in mesa will give a better impression of how much it actually does.
[11:52:53 CEST] <nevcairiel> long long ago, first gen AMD decoders i think
[11:53:13 CEST] <jya> ok... so I'm going to store it as the original... no zigzag
[11:56:18 CEST] <jya> nevcairiel: if you zigzag twice you get back to the original ? (haven't thought about it really)
[12:00:06 CEST] <nevcairiel> not exactly
[12:00:13 CEST] <nevcairiel> but you can reverse it of course
[12:00:49 CEST] <nevcairiel> like the line of code above, if you loop over "j" and then read it zigzagged from one and write it non-zig to the other, you basically reverse it
[12:01:26 CEST] <jya> i see... thanks for pointing that out
[12:01:33 CEST] <nevcairiel> during sps/pps parsing its the other way around, you read value "j" and then write it into zigzag[j]
[12:01:58 CEST] <jya> cool!
[12:13:09 CEST] <jya> nevcairiel: would you know of any samples where scaling tables are declared? i tried a few videos I have, and all of them use default stuff (eg. all 16)
[12:13:40 CEST] <nevcairiel> i would assume one of the conformance samples would have one
[12:15:59 CEST] <nevcairiel> http://fate-suite.ffmpeg.org/h264-conformance/FRext/Freh1_B.264 this one supposedly
[12:19:32 CEST] <jya> what container is that?
[12:19:36 CEST] <nevcairiel> none
[12:20:03 CEST] <JEEB> raw annex b
[12:20:09 CEST] <jya> ah... will be hard for me to verify if my code is valid
[12:20:20 CEST] <nevcairiel> well you can just remux it with ffmpeg if you need to
[12:20:45 CEST] <jya> ffmpeg will understand .264 to be annexb?
[12:20:48 CEST] <JEEB> yes
[12:21:03 CEST] <JEEB> or do -f h264 before input
[12:34:36 CEST] <jya> nevcairiel: nope :( no defined scale tables in that one
[12:40:49 CEST] <jkqxz> Er, yes it does.  <http://sprunge.us/YeWb>
[12:54:28 CEST] <jya> jkqxz: 
[12:55:05 CEST] <jya> jkqxz: the pps size is 6 bytes long.
[12:55:35 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:73ead477ddd9: lavf: add AV_DISPOSITION_TIMED_THUMBNAILS
[12:55:36 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:697400eac07c: lavf/mov: improve `tref/chap` chapter handling
[12:55:37 CEST] <cone-288> ffmpeg 03Rodger Combs 07master:490c6bda0e35: lavf/mov: reindent
[12:55:39 CEST] <jya> oh sorry, I was looking in the pps
[12:58:49 CEST] <jya> jkqxz: which tool did you use to print that?
[12:58:51 CEST] <jkqxz> Yeah, the scaling lists can be in the SPS and/or the PPS.  This one has them in the SPS.
[12:59:10 CEST] <jkqxz> The reference decoder (JM).
[13:04:40 CEST] <jya> well, the mp4 i converted i got with ffmpeg, seq_scaling_matrix_present_flag is 0
[13:04:47 CEST] <jya> what's going on in that stuff
[13:07:08 CEST] <jya> i get a length of 20 bytes in the SPS
[13:13:56 CEST] <jkqxz> You're reading the file as AVCC rather than annex B?  (I see a byte value 20 early in it.)
[13:20:00 CEST] <jya> jkqxz: no, I converted the .264 file into a .mp4
[13:20:09 CEST] <jya> the sps becomes 22 bytes then
[13:21:51 CEST] <jya> ffmpeg -i ~/Downloads/Freh1_B.264 -c:a copy ~/Downloads/Freh1_B.mp4 ; the level_idc goes from 22 to 13 etc
[13:23:48 CEST] <jkqxz> Copy the video ("-c:v copy") rather than the (nonexistent) audio?
[13:25:06 CEST] <jya> jeez.. bad copy/paste :(
[13:25:41 CEST] <jya> better go to bed now...
[17:15:20 CEST] <thegeek_> @michaelni: I mentioned a segmentation fault in FFv1 here the other day, I can repro now with a small diff to the muxing.c sample. https://trac.ffmpeg.org/ticket/5906
[17:22:31 CEST] <RiCON> jkqxz: tried latest two qsv patches: https://i.fsbn.eu/pub/qsv/
[20:22:22 CEST] <jkqxz> RiCON:  Looks like VC-1 and H.264 8-bit are fine, assuming the output was correct.  MPEG-2 doesn't work where mine does - can you share the input stream so I can try it?  H.265 8-bit appears to not manage to initialise at all, not sure what's going on there.  For the other two, H.26[45] 10-bit is indeed not supported.
[20:24:53 CEST] <RiCON> jkqxz: uploaded to the same dir
[20:28:05 CEST] <RiCON> i don't have any other mpeg-2 sample so it might just be that one
[20:34:23 CEST] <jkqxz> Ok, I do get the same behaviour with it.  I will investigate further; maybe tomorrow if I have time.
[20:34:36 CEST] <JEEB> talking of hwdec vc1, I still remember the 9600M of mine only doing it through the driver's SW decoder :D
[20:34:52 CEST] <JEEB> MPEG-2 and AVC worked fine, but VC-1 was given the short stick
[20:40:46 CEST] <tmm1> rcombs: lmk if i can provie any more information on this audiotoolbox deadlock ^^
[21:26:18 CEST] <wm4> tmm1: I think there are some cases where videotoolbox errors on streams that are perfectly fine hw-decodable on the same hw with vaapi or dxva
[21:26:37 CEST] <wm4> but which doesn't have to do with the extradata case
[21:26:56 CEST] <wm4> I think the same streams work if hardware decoding isn't forced
[21:27:11 CEST] <wm4> never investigated this too deeply
[21:54:22 CEST] <tmm1> wm4: if you have some samples i can take a look, it definitely seems very finicky
[21:54:30 CEST] <tmm1> even moreso on iOS
[21:54:48 CEST] <tmm1> i saw mpv has that hack where it switches back to software decoding after the first frame decode failure from VT
[21:55:53 CEST] <wm4> that's because of a hard to fix ffmpeg issue
[21:56:06 CEST] <wm4> which happens because VT doesn't really fit in as hwaccel
[22:04:28 CEST] <tmm1> i saw some talk of writing a vt decoder instead of using it as an hwaccel /cc rkern 
[22:04:52 CEST] <wm4> also cc rcombs 
[22:05:19 CEST] <wm4> I think rcombs got stuck with the reordering logic, since VT likes to return frames in decode order
[22:05:38 CEST] <wm4> and reordering requires dealing with the codec details (h264 in particular)
[22:08:23 CEST] <cone-915> ffmpeg 03Ronald S. Bultje 07master:be885da3427c: vp9: change order of operations in adapt_prob().
[22:08:24 CEST] <cone-915> ffmpeg 03Ronald S. Bultje 07master:f141ac4d0bf1: vf_colorspace: don't spam console with warnings if range is unspecified.
[22:08:25 CEST] <cone-915> ffmpeg 03Vittorio Giovara 07master:ba53d3ae8bfb: vf_colorspace: Add support for iec61966-2.1 (sRGB) transfer
[22:18:47 CEST] <rkern> I'd rather a vt decoder over the hwaccel. rcombs, does anything else besides reordering need to be done?
[22:33:20 CEST] <ubitux> it's pretty much blocking
[22:33:32 CEST] <ubitux> because you don't want to duplicate the reordering logic
[22:36:09 CEST] <nevcairiel> i still dont get whats wrong with a hwaccel
[22:36:14 CEST] <nevcairiel> let the  code we have do the work
[22:39:51 CEST] <wm4> it doesn't quite fit architecturally, and we probably won't be able to use VT's async decoding mode
[22:40:37 CEST] <ubitux> yes you can't do async properly
[22:40:49 CEST] <ubitux> (and async is mandatory if you want to decent performance)
[22:41:01 CEST] <nevcairiel> leave it to apple to build something that doesnt work like anything else - using the same hardware :p
[22:41:47 CEST] <wm4> of course
[22:42:03 CEST] <wm4> apple loves this kind of stuff
[22:46:04 CEST] <rkern> What's the issue with async?
[22:48:02 CEST] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg.c;h=3b9171090f2676f5fa8b6abb11e4cf95d9fb67b3;hb=HEAD#l2319
[22:48:13 CEST] <ubitux> am i being dumb again?
[22:48:25 CEST] <ubitux> or the frame_sample_aspect in the loop makes no sense?
[22:50:02 CEST] <ubitux> aside from that and the last err check, this whole loop is identical between audio and video; it should probably be homogenised and shared
[22:50:35 CEST] <wm4> rkern: hwaccels use the hwaccel backend in synchronous mode obviously
[22:51:15 CEST] <wm4> ubitux: seems like it picks the first valid aspect or something?
[22:51:54 CEST] <ubitux> ist doesn't change in that loop
[22:52:00 CEST] <ubitux> nor frame_sample_aspect
[22:52:05 CEST] <ubitux> unless i'm missing something obvious
[22:52:18 CEST] <wm4> why is this code so hideous
[22:52:33 CEST] <wm4> why doesn't it do &decoded_frame->sample_aspect_ratio or whatever
[22:53:49 CEST] <wm4> ubitux: maybe it being in the loop is a merge error?
[22:54:11 CEST] <ubitux> might be
[22:54:17 CEST] <ubitux> i guess i'll send a few patches
[22:55:05 CEST] <tmm1> sounds like kVTDecodeFrame_EnableTemporalProcessing is just ignored altogether..
[22:55:31 CEST] <ubitux> yes it is
[22:55:50 CEST] <ubitux> there are a ton of "funny" things with VT
[22:56:17 CEST] <wm4> yeah, rcombs investigated this "fun"
[22:56:29 CEST] <wm4> seems like you really have to do it manually
[22:57:03 CEST] <tmm1> yea looks like everyone else is doing manual reordering, based on pts?
[22:57:55 CEST] <nevcairiel> pts is not a concept i would ever accept
[22:57:58 CEST] <nevcairiel> timestamps are volatile
[22:58:12 CEST] <nevcairiel> either do it correctly or dont bother
[22:58:37 CEST] <wm4> I know chromium does it by duplicating the h264 picture output logic
[22:58:43 CEST] <wm4> which is annoying
[23:09:12 CEST] <ubitux> tmm1: 2 other "fun" things:
[23:09:21 CEST] <ubitux> - pushing more than 3 packets to VT will cause a fatal deadlock when the application is going in background on iOS
[23:09:31 CEST] <ubitux> so you have to create a lock by yourself
[23:09:50 CEST] <JEEB> lol
[23:09:50 CEST] <ubitux> - The decode callback can actually be called after VTDecompressionSessionWaitForAsynchronousFrames()
[23:10:07 CEST] <ubitux> (on some relatively old iOS versions)
[23:10:13 CEST] <ubitux> so you actually have to count the frames too
[23:11:35 CEST] <ubitux> i also have to investigate some funny business related to h264 extradata
[23:11:44 CEST] <ubitux> but that will be another story
[23:16:59 CEST] <tmm1> gosh
[23:56:22 CEST] <rkern> tmm1: I've had some luck with avfoundation... Maybe the indev could be modified to accept files too.
[23:56:33 CEST] <rkern> Won't work for all use cases though.
[00:00:00 CEST] --- Tue Oct 25 2016