<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi</div><div class=""><br class=""></div><div class="">I'm trying to fix this bug in VideoToolbox:</div><div class=""><br class=""></div><div class=""><a href="https://trac.videolan.org/vlc/ticket/18416" class="">https://trac.videolan.org/vlc/ticket/18416</a></div><div class=""><br class=""></div><div class="">It was introduced by this commit:</div><div class=""><br class=""></div><div class=""><a href="https://github.com/videolan/vlc/commit/b6d73612d383b25ab12e2f8aad289d045200281a" class="">https://github.com/videolan/vlc/commit/b6d73612d383b25ab12e2f8aad289d045200281a</a></div><div class=""><br class=""></div><div class="">I've traced it through to the code block below in hxxx_helper.c, inside h264_helper_parse_nal:</div><div class=""><br class=""></div><div class="">What is happening is that every few seconds (every keyframe?) it is detecting a new PPS and thus setting *p_config_changed to true, which causes the decoder to be restarted. This leads to the green corruption.</div><div class=""><br class=""></div><div class="">I found that:</div><div class=""><br class=""></div><div class="">- helper_search_pps detects that the PPS is different. i_nal is normally 82 but every few seconds a PPS arrives of size 53 and this one triggers the change</div><div class="">- despite the above, all entries of the h264_picture_parameter_set_t structure are the same, although I noticed that in h264_parse_picture_parameter_set_rbsp in h264_nal.c it only parses and reads in a few of them</div><div class="">- if I disable the line that sets *p_config_changed = true it fixes the bug with no visible side-effects</div><div class=""><br class=""></div><div class="">So a couple of Qs to anyone familiar with this area:</div><div class=""><br class=""></div><div class="">1) is it correct behaviour to restart the decoder whenever the PPS changes?</div><div class="">2) if yes, what are the circumstances where it should restart the decoder/set config_changed to true, because it would seem that this shouldn't be one of them.</div><div class="">3) if no, then it's a simple patch not to set *p_config_changed to true, correct?</div><div class=""><br class=""></div><div class="">Note that this issue seems specific to interlaced content. I've not seen it with progressive content and as you will see from the bug report it has been independently reported with other interlaced h.264 files too.</div><div class=""><br class=""></div><div class="">Regards</div><div class=""><br class=""></div><div class="">Oliver</div><div class=""><br class=""></div><div class=""> else if (i_nal_type == H264_NAL_PPS)</div><div class=""> {</div><div class=""> if (helper_search_pps(hh, p_nal, i_nal) != NULL)</div><div class=""> continue;</div><div class=""> h264_picture_parameter_set_t *p_pps =</div><div class=""> h264_decode_pps(p_nal, i_nal, true);</div><div class=""> if (!p_pps)</div><div class=""> return VLC_EGENERIC;</div><div class=""><br class=""></div><div class=""> struct hxxx_helper_nal *hnal = &hh->h264.pps_list[p_pps->i_id];</div><div class=""><br class=""></div><div class=""> if (helper_dup_buf(hnal, p_nal, i_nal))</div><div class=""> {</div><div class=""> h264_release_pps(p_pps);</div><div class=""> return VLC_EGENERIC;</div><div class=""> }</div><div class=""> if (hnal->h264_pps)</div><div class=""> h264_release_pps(hnal->h264_pps);</div><div class=""> else</div><div class=""> hh->h264.i_pps_count++;</div><div class=""><br class=""></div><div class=""> hnal->h264_pps = p_pps;</div><div class=""> *p_config_changed = true;</div><div class=""> msg_Dbg(hh->p_obj, "new PPS parsed: %u", p_pps->i_id);</div><div class=""> }</div><div class=""><br class=""></div></body></html>