[vlc-devel] VideoToolbox green corruption bug

[Oliver Collyer]

> On 10 Jul 2017, at 15:43, Oliver Collyer <ovcollyer at mac.com> wrote:
> 
>> 
>> On 10 Jul 2017, at 14:27, Francois Cartegnie <fcvlcdev at free.fr> wrote:
>> 
>> Le 07/07/2017 à 22:00, Oliver Collyer a écrit :
>> 
>>> I found that:
>>> 
>>> - 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
>> 
>> So it's different. And in H264 spec, any pps with same id replaces the
>> previous one in transmission order.
>> 
>>> - 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
>> 
>> Not the same. Both have different scaling lists.
>> 
>>> - if I disable the line that sets *p_config_changed = true it fixes the bug with no visible side-effects
>>> 
>>> So a couple of Qs to anyone familiar with this area:
>>> 
>>> 1) is it correct behaviour to restart the decoder whenever the PPS changes?
>> 
>> You're supposed to restart decoder because it is dumb and can't handle
>> SPS/PPS updates by itself.
>> 
>>> 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.
>> 
>> When the SPS/PPS parameters change. Which does here.
>> 
>> There's not much description about how to handle those cases...
>> That's "Apple standards" in high quality API.
>> 
>> You have to figure out how and if it will works, gather the hw
>> differences and add targeted hacks by yourself (You can't query
>> capabilities ! Which seems lots of unpublished internal conditional
>> switches in Foundation)
>> 
>> Since you're restarting both on Iframe and Iframe+1, there can only be
>> corrupted output.
>> 
>>> 3) if no, then it's a simple patch not to set *p_config_changed to true, correct?
>> 
>> No.
>> 
>>> 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.
>> 
>> That's a corner case with what seems a broken H264 stream (if they need
>> to feed different scaling lists, then a different PPS should probably be
>> used). As they do transmit the same pps with each frame that's a strong
>> signal they don't really understand how it works.
>> 
> 
> Thankyou for all that useful information.
> 
> The only other thing I didn't mention was that in the case of the stream I'm testing it was originally captured as an h.264 ASF file directly from a Slingbox. When the container is ASF then VLC can play the stream without these issues.
> 
> I then used ffmpeg to change the container to a transport stream without re-encoding and it is at this point that it introduces the problem.
> 
> I'm not sure what that points to because if it was a problem with the underlying h.264 stream then I would have thought it would also manifest within ASF too?
> 
> I think what I will do next is see what PPS changes occur when I play it back through ASF and see if that gives any clues.
> 

Ok, on further investigation VT actually doesn't get chosen for the ASF version of this file, it reverts to software decoding, which looks like a separate bug.

>> Francois
>> _______________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel <https://mailman.videolan.org/listinfo/vlc-devel>
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel <https://mailman.videolan.org/listinfo/vlc-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20170710/b4dabf44/attachment.html>