Recherche avancée

Sur d’autres sites (4927)

• Evolution #4346 (En cours) : Extraire la gestion des catégories de SPIP et SVP (action 1)

  11 juin 2019, par Eric Lupinacci

  Le passage sous Composer va à plus ou moins long terme remettre en cause SVP. SVP supporte aujourd’hui plusieurs fonctions distinctes dont :

  1. la "gestion" des catégories
  2. la "gestion" des branches SPIP
  3. la construction du référentiel des plugins et des dépôts.
  4. l’installation des plugins incluant la gestion des dépendances.

  La mise en place de Composer (objectif final avec les plugins) remet en cause complètement la fonction 4-.
  L’idée est donc :

  • action 1 : transférer la fonction 1 dans un plugin à part : c’est déjà fait en grande partie et le plugin s’appelle SVP Typologie.
  • action 2 : transférer la fonction 2 dans SPIP directement (ou ailleurs, à réfléchir). Cela correspond principalement à des globales et une balise.
  • action 3 : transférer la fonction 3 dans un plugin "Référentiel des plugins" qui construit la base des plugins à partir des archives XML. En complément, il serait bien de réfléchir à une autre manière d’intégrer dans le référentiel les plugins Github de façon corriger les liens erronés puis ensuite de rajouter les zips Composer.
  • action 4 : réduire SVP à la fonction 4 en nécessitant le plugin "Référentiel des plugins" pour un certain temps.

  Ce ticket est avant tout dédié à l’action 1.
  Outre le plugin SVP Typologie développé pour l’instant sur Github https://github.com/smellup/svp_typologie il faut aussi faire des modifications sur SVP et le Core.

  Pour le Core, il faut :

  • passer la catégorie en optionnelle, supprimer la liste des valeurs possibles afin de ne pas générer d’erreur. Une fois les nouvelles catégories adoptées, on pourra même supprimer la catégorie des fichiers XML.
  • vérifier que les références à la catégorie dans les fonctions de chargement des XML sont compatibles avec l’absence de catégorie (a priori c’est le cas dans info_plugin).

  Pour SVP, il faut :

  • supprimer les balises, filtres et globales associés aux catégories
  • certains autres filtres (comptage en particulier) ne sont utilisés que dans Plugins SPIP. Il convient de les déplacer dans le plugin idoine (Plugins SPIP ou Contrib à terme)
  • Supprimer le filtre catégorie dans le formulaire de recherche des plugins.

• Logic and lawyers

  22 mai 2013, par Mans — Law and liberty

  Reading about various patent litigation cases, I am struck by the frequency with which common logical fallacies such as the Appeal to Consequences are committed. We shall look at a couple of recent examples.

  In conjunction with the Federal Circuit ruling in CLS Bank v. Alice Corp., Judge Moore, joined by three others, filed a dissenting opinion wherein we find the following :

  I am concerned that the current interpretation of § 101, and in particular the abstract idea exception, is causing a free fall in the patent system. [...] And let’s be clear : if all of these claims, including the system claims, are not patent-eligible, this case is the death of hundreds of thousands of patents [...].

  A footnote adds :

  If the reasoning of Judge Lourie’s opinion were adopted, it would decimate the electronics and software industries. [...] There has never been a case which could do more damage to the patent system than this one.

  From the above, I get the impression Moore is primarily concerned with protecting the system, maintaining the status quo, less with ruling in line with the logical consequences of statute and case law. Furthermore, her argument rests on the premise that a weaker patent system would “decimate the industries,” a notion supported by little evidence, yet presented by Moore as an obvious truth. In fact, research exists suggesting that many important innovations are never actually patented. Let us also not overlook the fact that European companies do not appear to be suffering from the much weaker patent protection for software afforded there.

  Judge Moore’s reasoning can be summarised in three steps :

  1. Ruling this way could be disruptive to the patent system.
  2. The industry relies on patents.
  3. Therefore we must not rule this way.

  Not only does she commit the aforementioned logical fallacy, she does so by way of invalid arguments.

  The second example of such fallacious reasoning comes from the Supreme Court ruling in Bowman v. Monsanto :

  We have always drawn the boundaries of the exhaustion doctrine to exclude that activity [copying], so that the patentee retains an undiminished right to prohibit others from making the thing his patent protects. [...] That is because, once again, if simple copying were a protected use, a patent would plummet in value after the first sale of the first item containing the invention. The undiluted patent monopoly, it might be said, would extend not for 20 years (as the Patent Act promises), but for only one transaction. And that would result in less incentive for innovation than Congress wanted. Hence our repeated insistence that exhaustion applies only to the particular item sold, and not to reproductions.

  Here we find the same pattern repeated. The aim of the court appears to have been ensuring the continued validity of this class of patents, not reaching a logical conclusion regarding the question of infringement. Once again, we can break the reasoning down into three steps :

  1. A non-infringement ruling would weaken the patent.
  2. Weaker patents would provide less incentive for innovation.
  3. Therefore we must rule infringement.

  As in the first example, the argument presented in step two is at best questionable, and no supporting evidence is provided.

  These are, unfortunately, not the only examples of such fallacies ; one might even describe them as ubiquitous. Does a law education not include any material on logical reasoning ? Ought it not ? While we can never hope to find any kind of universal truth on which to base our laws, we should at least strive to make our system logically consistent. If we do not, notions such as fairness and justice lose their meanings.

• Android Camera Video frames decoding coming out distorted with horizontal lines

  13 novembre 2018, par Iain Stanford

  I’ve been porting over the following Test Android example to run in a simple Xamarin Android project.

  https://bigflake.com/mediacodec/ExtractMpegFramesTest_egl14.java.txt

  I’m running a video captured by the camera (on the same device) through this pipeline but the PNGs I’m getting out the other end are distorted, I assume due to the minefield of Android Camera color spaces.

  Here are the images I’m getting running a Camera Video through the pipeline...

  https://imgur.com/a/nrOVBPk

  Its hard to tell, but it ’kinda’ looks like it is a single line of the actual image, stretched across. But I honestly wouldn’t want to bank on that being the issue as it could be a red herring.

  However, when I run a ’normal’ video that I grabbed online through the same pipeline, it works completely fine.

  I used the first video found on here (the lego one) http://techslides.com/sample-webm-ogg-and-mp4-video-files-for-html5

  And I get frames like this...

  https://imgur.com/a/yV2vMMd

  Checking out some of the ffmpeg probe data of the video, both this and my camera video have the same pixel format (pix_fmt=yuv420p) but there are differences in color_range.

  The video that works has,

  color_range=tv
  
  color_space=bt709
  
  color_transfer=bt709
  
  color_primaries=bt709

  And the camera video just has...

  color_range=unknown
  
  color_space=unknown
  
  color_transfer=unknown
  
  color_primaries=unknown

  The media format of the camera video appears to be in SemiPlanar YUV, the codec output gets updated to that at least. I get an OutputBuffersChanged message which sets the output buffer of the MediaCodec to the following,

  {
  
      mime=video/raw,
  
      crop-top=0, 
  
      crop-right=639, 
  
      slice-height=480,
  
      color-format=21,
  
      height=480, 
  
      width=640, 
  
      what=1869968451, 
  
      crop-bottom=479, 
  
      crop-left=0, 
  
      stride=640
  
  }

  I can also point the codec output to a TextureView as opposed to OpenGL surface, and just grab the Bitmap that way (obviously slower) and these frames look fine. So maybe its the OpenGL display of the raw codec output ? Does Android TextureView do its on decoding ?

  Note - The reason I’m looking into all this is I have a need to try and run some form of image processing on a raw camera feed at as close to 30fps as possible. Obviously, this is not possible some devices, but recording a video at 30fps and then processing the video after the fact is a possible workaround I’m investigating. I’d rather try and process the image in OpenGL for the improved speed than taking each frame as a Bitmap from the TextureView output.

  In researching this I’ve seen someone else with pretty much the exact same issue here How to properly save frames from mp4 as png files using ExtractMpegFrames.java ?
  although he didn’t seem to have much luck finding out what might be going wrong.

  EDIT - FFMpeg Probe outputs for both videos...

  Video that works - https://justpaste.it/484ec .
  Video that fails - https://justpaste.it/55in0 .