<html><head></head><body>I agree that picture_t.context and picture_t.sys should be unified when push buffers are ready. But that's not the problem.<br><br>There're 3 places that a picture can refer to its video context: in picture_t, in the common part of the picture context, or in the type-specific part of the picture context (where the proto-video_context currently are). Since there should not be pictures with video context and without picture context, I don't see the benefit of the first option. It just adds a potentially useless member.<br><br><div class="gmail_quote">Le 12 novembre 2019 09:24:18 GMT+02:00, Steve Lhomme <robux4@ycbcr.xyz> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On 2019-11-09 3:40, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Le vendredi 8 novembre 2019, 16:40:05 EET Steve Lhomme a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">The video context is only held if the picture is created successfully. It is<br>released after the picture is destroyed.<br></blockquote>Seems redundant with existing picture context, which typically refers to the<br>video context in a way or other - unless the goal is to remove the picture<br>context - which seems unrealistic to me.<br><br>Maybe we should actually "standardize" the reference from the picture context<br>to the video context, but I don't see the need for yet another member in<br>crowded picture_t.<br></blockquote><br>Adding the video context to the picture is exactly what was decided with <br>push. The fact it's also used the first time the vout is initialized is <br>a necessary mean to get there. In some of the proposed patches the video <br>context from the picture is already used as such instead of getting it <br>from the decoder/filter.<br><br>I agree there's probably one too many between the picture_sys_t, the <br>picture_context_t and the video_context. At least the video context <br>exists on its own without a picture (as already used in current master). <br>Adding the destroy/clone callbacks from the picture_context_t would make <br>no sense when used without a picture.<br><br>The picture_sys is probably a better candidate to remove from the <br>picture. In D3D the picture_context_t already has a picture_sys_t <br>because they may exist in some cases and not others (depending if they <br>came from the decoder or the display). All this will be gradually <br>removed and ultimately there won't be any picture_sys_t there. I think <br>it can be the same for other formats.<br><br>This cleaning should happen at the end though. We can only guarantee the <br>picture_sys_t is not needed anymore once eveything is safely moved there <br>and the picture_sys_t are never used anymore. For now I'm concentrating <br>on architectural changes.<hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>