[FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames

[Timo Rothenpieler]

Am 17.10.2017 um 20:37 schrieb Thilo Borgmann:
> Am 17.10.17 um 20:27 schrieb wm4:
>> On Tue, 17 Oct 2017 20:23:25 +0200
>> Thilo Borgmann <thilo.borgmann at mail.de> wrote:
>>
>>> Am 17.10.17 um 06:49 schrieb wm4:
>>>> I have realized that your veto is actually not valid:
>>>> - it's a Libav merge
>>>> - it has been for months in the Libav repo and you didn't specifically
>>>>    care, nor did you make an attempt to merge the commit in a "fixed" way
>>>> - this patch would have been merged normally, and you wouldn't have
>>>>    cared at all about it
>>>>
>>>> So unless you intend to make a better, working proposal, I will _not_
>>>> allow you to make this "my" problem. I will psuh this in 3 hours. After
>>>> that, you're free to to reimplement this in a different way or whatever
>>>> as a merge cleanup.
>>>
>>> Can you please stop this and just find a reasonable way to find consensus on the issues you're facing?
>>>
>>> Is it really of such importance that you want to push this although there are still concerns about what you want to do? Is this at all in any way relevant for security so that time would be at all a factor? I don't see any of your arguments mentioned above to be a valid reason to overrule someone else's opinion.
>>
>> I don't want trivial things getting blocked by pure bullshit that's
>> probably politically and not technically motivated.
>>
>> The best part about this dumb shit is that I could probably send
>> patches for cuvid/videotoolbox that use dumb workarounds (i.e. uglier
>> and shittier hacks) than the discussed patch, and NOBODY WOULD FUCKING
>> CARE.
>>
>> I'm pretty fed up with this shit.
>>
>> Please keep out of this discussion if you can't contribute anything too.
> 
> I do care because I am delaying my work on some other cuvid related thing because of this.
> 
> I would prefer not to dive into this topic any further because it seems rather "not so important" to my task. And just another cook in the kitchen would also more likely avoid conensus here.
> 
> All I ask for is for you to find a reasonable to argue about your issues.
> 
> I hope you see my point why I am raising my voice. Thanks!
> 
> -Thilo
I second this. The exact way this is implemented is entirely 
unimportant. But this pointless fighting leads nowhere.
While I agree that this patch is technically correct and does not 
violate API in any way, I also kind of dislike using opaque_ref for 
this, and would welcome coming up with a nicer solution, that's ideally 
compatible with libavs approach without too much work on every patch 
that touches it.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3994 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171017/ba80f827/attachment.bin>