{"push_id":592356717,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"978d7b2e8fb386e89b94769de0ffbe5c8ab624f8","before":"a5df38ce5d1747f065556b3a838348feac9d76d5","commits":[{"sha":"978d7b2e8fb386e89b94769de0ffbe5c8ab624f8","author":{"email":"9ce5770b3bb4b2a1d59be2d97e34379cd192299f@borho.org","name":"Steve Borho"},"message":"frameencoder: avoid race hazard in end of frame logic\n\nThis bug has been in the encoder, latent, for about 6 months so it deserves an\nobituary (being somewhat presumptuous that this commit actually kills it). The\nbug worked in this way:\n\n1. user starts an encode of a small resolution encode at superfast preset,\n   generating frame rates of about 200-300 fps depending on the hardware.\n\n2. a worker thread finishes compressing all of the CTUs in its row, but then\n   gets evicted from its core before it is allowed to flush its row bitstream\n   object (leaving four bytes within the Entropy object unwritten)\n\n3. The other threads quickly finish the rest of the frame and the worker which\n   compressed the last row signals frame completion.\n\n4. The frame encoder thread concatenates the row bitstreams together and emits\n   the NAL. If you were lucky, the row that was evicted would have been 4 bytes\n   long since the 0 byte length triggers a check failure indicating something is\n   seriously wrong. If you're un-lucky the NAL is garbage and does evil things\n   to your decoder.\n\n5. the evicted worker finally gets back on the core and flushes its bitstream,\n   to the aid of no-one.\n\nWith this commit, we note when the last row has been compressed (indicating all\nCTUs in the frame are compressed) but we do not signal that the frame is\ncomplete until the last worker thread leaves processRow() (taking advantage of\nthe recently introduced atomic count of workers).","distinct":true,"url":"https://api.github.com/repos/videolan/x265/commits/978d7b2e8fb386e89b94769de0ffbe5c8ab624f8"}]}