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

[burek]

[00:04:16 CEST] <durandal_1707> michaelni: i have mjpeg sample that shows our mjpeg parser is buggy
[00:15:40 CEST] <tmm1> definitely something strange going on with these trailing zeros in the slice
[00:15:53 CEST] <mkver> And what is going on?
[00:16:42 CEST] <mkver> These cabac zero words should initially be 0x00 00 03 (the last one is an emulation_prevention_three_byte).
[00:18:56 CEST] <tmm1> it seems like in the original sample the first slice has 5 zero bytes at the end 
[00:19:00 CEST] <tmm1> is `-f h264` in annexb format?
[00:19:03 CEST] <michaelni> durandal_1707, please provide a link or something. ill take a look (might be a few days as iam ATM a bit behind what i wanted to do)
[00:19:14 CEST] <mkver> Yes.
[00:20:02 CEST] <mkver> Can you upload your sample somewhere and explain what you did, what you expected and what you got?
[00:20:10 CEST] <tmm1> it seems like it shouldn't be possible to see five 0x00 in a row without a start code emulation
[00:20:20 CEST] <tmm1> yes see https://gist.github.com/tmm1/5737a57ea6b398d3e8d3cad4f12ebb49
[00:20:39 CEST] <mkver> It can be. It is allowed to add zeroes (arbirarily many) between annexb NAL units.
[00:21:04 CEST] <mkver> Our code drops them.
[00:21:51 CEST] <tmm1> i see, ok. if i alter ffmpeg to keep the trailing zeros in slices, when it regenerates the bitstream from cbc it escapes those trailing zeros with 0x03 bytes
[00:22:54 CEST] <mkver> Yes, because it currently doesn't distinguish between zeros created by unescaping and zeros that were between NAL units.
[00:23:45 CEST] <mkver> Also notice that the current code in assemble_fragment would not add a 0x03 escape at the very end of the NAL unit even if it should.
[00:24:23 CEST] <mkver> That's currently no problem, because there is no need to do so (after all the trailing zeroes have been dropped)
[00:28:21 CEST] <mkver> According to the standard, only parameter sets and the first NAL of an access unit need a four byte startcode; the others can have three byte startcodes.
[00:29:08 CEST] <mkver> assemble_fragment tries to use three-byte startcodes whenever possible. that explains the difference at byte 149/150.
[00:30:48 CEST] <mkver> Also notice that the h2645_parse functions are a bit buggy: If a NAL unit has a four byte startcode, they will add a zero byte at the end of the preceding NAL unit and treat the unit as if it had a three-byte startcode.
[00:37:14 CEST] <tmm1> hmm interesting
[00:37:44 CEST] <mkver> And what is actually your problem?
[00:39:17 CEST] <tmm1> the problem is an android hardware decoder that's choking on the bitstream when i use h264_metadata_bsf 
[00:40:37 CEST] <tmm1> i think i managed to patch cbs so the input and output across h264_bitstream are bitexact, so now i should be able to verify if cbs is the issue or not
[00:45:05 CEST] <mkver> Your sample uses four byte startcodes for the slices. Maybe it's that? Use a hex editor and prepend a zero to all occurences of 0x00 00 01 41 and 0x00 00 01 01.
[00:47:49 CEST] <mkver> Alternatively, you could test whether the chomp bitstream filter also makes the output unplayable with your device. It would only remove the trailing zeroes after the slice, but leave the other startcodes alone.
[00:55:22 CEST] <tmm1> ok it looks like the start code change doesn't matter
[00:55:38 CEST] <tmm1> by keeping the trailing slice bytes it plays correctly on the device
[00:55:39 CEST] <tmm1> https://gist.github.com/tmm1/5737a57ea6b398d3e8d3cad4f12ebb49#file-h264bsf-patch
[00:55:47 CEST] <tmm1> i will try chomp to verify as well, good idea
[00:59:13 CEST] <mkver> Your patch will not make output bitexact if a slice ends in a cabac_zero_word.
[01:00:51 CEST] <tmm1> chomp breaks playback in the same spot
[01:00:55 CEST] <mkver> And if a slice is followed by another unit that uses a four byte start code, then a zero will be appended to that slice.
[01:01:07 CEST] <tmm1> so that confirms the decoder wants the trailing zeros in the slices for some reason
[01:05:43 CEST] <tmm1> now that i know what's going on.. is it worth pursing my patch to have ffmpeg keep trailing zeros for slices (i.e. would something like that get merged), or should i just find a simpler workaround/hack for this device
[01:06:38 CEST] <mkver> Fixing h2645_parse to no longer move the first byte of a four-byte startcode to the end of the preceding NAL unit would get merged.
[01:10:38 CEST] <mkver> But I don't know whether the other stuff would. I don't think that the non-cabac-zero-word zero bytes between slices should be kept; or if they can be kept at all.
[01:11:49 CEST] <tmm1> yea it does seems silly to keep zero bytes stuffed in between NALs
[01:12:33 CEST] <mkver> There is another complication here: If you modify the slice header and make it shorter, your code would add a zero at the end to make up for that; if you make it longer, your code would add less zeros than it would otherwise do.
[01:13:32 CEST] <mkver> Also these zero bytes in between NALs are an annexb thing; they are actually illegal in mp4 (but decoders don't seem to care).
[01:14:13 CEST] <tmm1> yea the patch would need a lot of work before being proposed, and still likely to get rejected since it doesn't make any sense outside this one broken device
[01:14:33 CEST] <tmm1> i just did the bare minimum to make input/output identical so i could narrow down the hardware bug
[01:14:43 CEST] <tmm1> the most straightforward patch that would fix my usecase is probably to update h264_metadata so it doesn't rewrite the bitstream when only PASS/EXTRACT options are used
[01:15:43 CEST] <tmm1> or i could add another option to stuff some number of zeros between NALs and that would probably be an effective workaround too
[01:18:32 CEST] <mkver> h2645_cbs always drops those zero bytes, even if you don't change a NAL unit and if you don't rebuild the NAL units from their decomposed form.
[01:18:49 CEST] <mkver> I.e. it also happens in filter_units.
[01:23:11 CEST] <tmm1> from lavc perspective it seems pretty reasonable that it removes these zeros
[03:12:36 CEST] <cone-664> ffmpeg 03Jun Zhao 07master:88a9998fe8c7: lavfi/colorspace: typedef ThreadData as all other filters
[03:12:36 CEST] <cone-664> ffmpeg 03Jun Zhao 07master:a0e03589d47f: lavfi/lenscorrection: remove unnecessary cast for void *
[03:12:36 CEST] <cone-664> ffmpeg 03Jun Zhao 07master:cc52815b8204: lavfi/remap: remove unnecessary cast for void *
[03:12:36 CEST] <cone-664> ffmpeg 03Jun Zhao 07master:7ab4fbdebcf1: lavfi/v360: remove unnecessary cast for void *
[03:33:44 CEST] <cone-664> ffmpeg 03Jun Zhao 07master:da0c0c7247fb: lavfi/hqdn3d: add slice thread optimization
[03:59:37 CEST] <cone-664> ffmpeg 03Steven Liu 07master:6f84c1e9078b: avformat/jvdec: fix memleak when read_header failed
[03:59:38 CEST] <cone-664> ffmpeg 03Steven Liu 07master:9f0b9ae8bd84: avformat/iff: fix memleak when get st->codecpar->extradata failed in iff_read_header
[04:27:26 CEST] <cone-664> ffmpeg 03Steven Liu 07master:aea82dfe225e: avfilter/vf_delogo: add auto set the area inside of the frame
[04:27:27 CEST] <cone-664> ffmpeg 03Steven Liu 07master:a76a516e761a: avfilter/vf_delogo: make the interp value compute method simple
[13:08:14 CEST] <durandal_1707> michaelni: did you got sample?
[13:09:05 CEST] <michaelni> yes i downloaded the mjpeg file, did not yet had time to look at it
[14:36:12 CEST] <cone-984> ffmpeg 03Michael Niedermayer 07master:4a3303d52096: avcodec/fitsdec: Fail on 0 naxisn
[14:36:12 CEST] <cone-984> ffmpeg 03Michael Niedermayer 07master:080819b3b4b5: avcodec/exr: Allow duplicate use of channel indexes
[14:36:12 CEST] <cone-984> ffmpeg 03Michael Niedermayer 07master:b3c25263d1ee: avcodec/scpr: Check minimum size of type 17
[14:36:12 CEST] <cone-984> ffmpeg 03Limin Wang 07master:6d18b62db96b: avcodec/magicyuv: remove duplicate code
[14:36:12 CEST] <cone-984> ffmpeg 03Michael Niedermayer 07master:5de19160a3c0: avcodec/pcm: Check bits_per_coded_sample
[14:36:12 CEST] <cone-984> ffmpeg 03Michael Niedermayer 07master:a5d29812ec36: avcodec/wmaprodec: Fix cleanup on error
[14:36:12 CEST] <cone-984> ffmpeg 03Michael Niedermayer 07master:f6df99dba1ae: avcodec/dstdec: Check for input exhaustion
[14:55:24 CEST] <BtbN> This ff_filter_process_command patchset really shows the downsides of using mailing lists. Over 100 new mails.
[17:29:33 CEST] <durandal_1707> michaelni: why noise shaping is done only when resampling?
[17:40:14 CEST] <michaelni> durandal_1707, is it? that sounds like it should not be limited that way
[17:43:31 CEST] <cehoyos> Registration opens soon.
[17:44:37 CEST] <BBB> soon
[17:46:20 CEST] <durandal_1707> what?
[17:53:57 CEST] <thilo> soon
[17:56:59 CEST] <durandal_1707> michaelni: flags/swr_flags is 0 by default
[17:58:16 CEST] <durandal_1707> thilo: registration for what?
[17:58:42 CEST] <thilo> durandal_1707: VDD
[18:13:39 CEST] <BradleyS> noise shaping by default is evil imho
[19:18:40 CEST] <Lynne> haasn: if you're getting GPU freezes with intel: its a known driver bug, there's an issue open
[19:19:52 CEST] <Lynne> its the same bug I've been getting, and its because their SIMD implementation seems to overread into DMABUF imported textures (which I think are somehow slightly different than native textures the driver allocates normally)
[19:24:11 CEST] <BBB> should've written the driver in python and we would all have been save
[19:26:40 CEST] <kierank> should've written it in rust
[19:34:33 CEST] <durandal_1707> dav1d should be written in rust
[19:35:19 CEST] <Chagall> as should ffmpeg
[19:36:34 CEST] <durandal_1707> in your dreams
[19:44:03 CEST] <JEEB> in theory writing a module in rust and pulling it around with the C FFI shouldn't be too hard
[19:44:16 CEST] <JEEB> I've been playing in my mind if I should make a PoC of that at some point
[20:12:53 CEST] <Lynne> rav1e has shown it was anything but easy and out of the box
[20:13:26 CEST] <Chagall> yeah, I researched it a little for another project and it is a pain
[20:14:38 CEST] <Chagall> you need a c-specific API and a header to go with it, which results in duplicated code and more difficult testing and maintenance
[20:14:49 CEST] <Lynne> in general its not even hip to NIH anything in rust but suffering using inflexible crates is very much a thing
[20:15:12 CEST] <JEEB> isn't the header generate'able with bindgen or so? or is bindgen just the other way?
[20:15:33 CEST] <Lynne> I kinda dislike the string-based C api rav1e used, feels like a workaround sort of
[20:15:55 CEST] <Chagall> JEEB: maybe, haven't tried using cbindgen
[20:16:36 CEST] <Chagall> Lynne: I agree but I'm not sure exactly what are the reasons behind that design
[20:16:46 CEST] <Chagall> I did think it was weird when I first really looked at it
[20:17:08 CEST] <JEEB> but yea, bindgen at least lets you go the other way (relatively) nicely
[20:17:09 CEST] <JEEB> https://github.com/jeeb/ffmpeg_ffi_test/blob/master/build.rs
[20:17:13 CEST] <JEEB> of course > crates
[20:17:19 CEST] <jamrial> Lynne: not really much different than x264's x264opts api
[20:18:36 CEST] <JEEB> and getting av_version_info utilized ended up like https://github.com/jeeb/ffmpeg_ffi_test/blob/master/src/main.rs
[20:18:45 CEST] <JEEB> so at least the other way (if you're OK with cargo) didn't seem too bad
[20:18:53 CEST] <JEEB> the problem is if you need to manually generate the stuff the other way
[20:26:32 CEST] <JEEB> -32
[21:06:56 CEST] <cone-436> ffmpeg 03Paul B Mahol 07master:b67af536be10: avfilter/vf_random: fix crash
[21:53:25 CEST] <cone-436> ffmpeg 03Paul B Mahol 07master:1331e001796c: avfilter/vf_floodfill: finish early if source and destination fill matches
[22:03:07 CEST] <Lynne> btw the 16 bit integer fft is actually used in the codebase, in the ac3_fixed encoder
[22:54:42 CEST] <michaelni> durandal_1707, that mjpeg is not just mjpeg. that are blocks of 4(size)+7680 bytes interleaved with jpeg images (7680 smells like audio /4*25=48000 but didnt confirm what that data is)
[22:55:27 CEST] <michaelni> the mjpeg parser has problems with the non mjpeg in there ...
[22:56:06 CEST] <michaelni> i do have a patch that makes the mjpeg parser more robust (needs a bit more testing) i guess it cant hurt to make it more robust
[22:56:46 CEST] <michaelni> but that file would probably best be handlled by a specific demuxer that seperates the non mjpeg out
[22:58:33 CEST] <thilo> are you watching mjpeg-football?
[22:58:49 CEST] <durandal_1707> yes
[23:00:01 CEST] <thilo> not surprised
[23:05:46 CEST] <durandal_1707> michaelni: binwalk sucessfully extract all jpg frames so its possible
[23:08:17 CEST] <michaelni> sure its possible, but dont you agree that this is better handled with a demuxer that does something with the other data too?
[23:13:37 CEST] <durandal_1707> michaelni: yes, but there are no headers and such
[23:14:14 CEST] <michaelni> yeah, i noticed that too
[00:00:00 CEST] --- Fri Oct 11 2019