Recherche avancée

Sur d’autres sites (8096)

• Optical Drive Value Proposition

  28 août 2010, par Multimedia Mike — General

  I have the absolute worst luck in the optical drive department. Ever since I started building my own computers in 1995 — close to the beginning of the CD-ROM epoch — I have burned through a staggering number of optical drives. Seriously, especially in the time period between about 1995-1998, I was going through a new drive every 4-6 months or so. This was also during that CD-ROM speed race where the the drive packages kept advertising loftier ‘X’ speed ratings. I didn’t play a lot of CD-ROM games during that timeframe, though I did listen to quite a few audio CDs through the computer.

  
  
  

  I use “optical drive” as a general term to describe CD-ROM drives, CD-R/RW drives, DVD-ROM drives, DVD-R/RW drives, and drives capable of doing any combination of reading and writing CDs and DVDs. In my observation, optical media seems to be falling out of favor somewhat, giving way to online digital distribution for things like games and software, as well as flash drives and external hard drives vs. recordable or rewritable media for backup and sneakernet duty. Somewhere along the line, I started to buy computers that didn’t even have optical drives. That’s why I have purchased at least 2 external USB drives (seen in the picture above). I don’t have much confidence that either works correctly. My main desktop until recently, a Mac Mini, has an internal optical drive that grew flaky and unreliable a few months after the unit was purchased.

  I just have really rotten luck with optical drives. The most reliable drive in my house is the one on the headless machine that, until recently, was the main workhorse on the FATE farm. The eject switch didn’t work correctly so I have to log in remotely, 'sudo eject', walk to the other room, pop in the disc, walk back to the other room, and work with the disc.

  Maybe optical media is on its way out, but I still have many hundreds of CD-ROMs. Perhaps I should move forward on this brainstorm to archive all of my optical discs on hard drives (and then think of some data mining experiments, just for the academic appeal), before it’s too late ; optical discs don’t last forever.

  So if I needed a good optical drive, what should I consider ? I’ve always been the type to go cheap, I admit. Many of my optical drives were on the lower end of the cost spectrum, which might have played some role in their rapid replacement. However, I’m not sold on the idea that I’m getting quality just because I’m paying a higher price. That LG unit at the top of the pile up there was relatively pricey and still didn’t fare well in the long (or even medium) term.

  Come to think of it, I used to have a ridiculous stockpile of castoff (but somehow still functional) optical drives. So many, in fact, that in 2004 I had a full size PC tower that I filled with 4 working drives, just because I could. Okay, I admit that there was a period where I had some reliable drives.

  That might be an idea, actually– throw together such a computer for heavy duty archival purposes. I visited Weird Stuff Warehouse today (needed some PC100 RAM for an old machine and they came through) and I think I could put together such a box rather cheaply.

  It’s a dirty job, but… well, you know the rest.

• Best intra-frame codec for editing ? Having color issues with DNxHR and serious sync issues with Prores

  23 janvier 2020, par Raulo1985

  I have a couple of questions regarding intra-frame codecs for editing purposes (in Premiere Pro).

  A LITTLE CONTEXT :

  I ripped a HDR movie to a MP4 container some months ago, using H.264 as codec (high 10, level 5, UHD, YUV, subsampling 4:2:0). The video looks great, as it should. Now I want to edit a trailer for that movie (I edit in Adobe Premiere Pro, current version), and for fast playback I need to work with proxies or transcode the source file to an intra-frame non long GOP file and use it as the source file (hopefully as lossless as that transcoding step can be). I tried for several days to transcode the source file to DNxHR 444 10 bits (using FFmpeg and then Adobe Media Encoder), but the result was always a video with the colors messed up (sometimes very washed out, sometimes over saturated).

  FFprobe of the resulting DNxHR file said that the color space was BT709 (source file is obviously BT2020), and I don’t know why. The transcoding involved upsampling since the source file is 4:2:0 and DNxHR doesn’t support it, but I tried upsampling to 4:4:4 and also to 4:2:2, and both of those files looked exactly the same to me, and very different from the original footage (so, I don’t think upsampling is the cause of the color issue, but maybe the apparent color space change or something wrong with the metadata). The results were the same when transcoding with Adobe Media Encoder. Anyway, I seem to have given up transcoding to DNxHR and use it as the source file, unless someone has an idea of what’s causing this problem. I could have worked with the source file for exporting and DNxHR LB for proxies, but there were sync issues (between source file and proxy) that defeated all purposes while editing. Prores is out of the picture, sync issues were worse (several seconds of delay).

  For the record, the command used that didn’t work as expected (color wise) is :

  ffmpeg -channel_layout 63 -i input.mkv -map 0:0 -c:v dnxhd -vf "scale=in_range=limited:out_range=full" -color_range 2 -profile:v dnxhr_444 -pix_fmt yuv444p10le -acodec pcm_s24le -ar 48000 -ac 6 -channel_layout 63 -map 0:2 -hide_banner output.mxf

  I also tried without the commands "scale=in_range=limited:out_range=full" and "-color_range 2", with same results. Always used FFmpeg latest version, and I’m working in Windows 10 Pro, latest drivers and latest Klite codec pack. Video files were compared with Mediainfo, FFprobe, and visually with VLC.

  Well, like I said, I’m giving up using DNxHR as the source file for my project (it would have been ideal since it doesn’t have sync issues with the DNxHR proxies, and file size is not a problem for me). A user here at the forums suggested transcoding and use H.264 intra-frame as source file, which I didn’t know was an option (I didn’t know H.264 was capable of intra-frame, my bad). I’m aware that one should avoid unnecesary transcoding steps, but I can’t work with a H.264 UHD HDR source file (ultra slow playback), and the sync issues with proxies, no matter the codec, make it impossible to make accurate cuts.
  So, bottom line, I need to find a way to fix the color issue when transcoding to DNxHR, or try with an inter-frame codec that’s not DNxHR and that’s capable of preserving all the HDR info (and then see if it doesn’t have sync issues. I’m assuming that those may dissapear when using intra-frame for both source file and proxies).

  NOTE : When importing the DNxHR 444 file to Premiere Pro and looking at the Lumetri scopes tab, you can tell that the colors are clipped at 100 nits, like a regular SDR video. So apparently the color space was really reduced to BT709, and I don’t know why. The H.264 source file behaves as expected, with colors going past 100 nits.

  MY QUESTIONS :

  1) Is H.264 intra-frame a good format for editing with a good playback performance ?

  2) If H.264 intra-frame is a good option, what would be the advantages of the DNxHR codec (or Prores) over it for editing purposes ? Everybody suggests DNxHD/DNxHR or Prores as intermediate codecs, but if intra-frame H.264 has the same advantages for editing and supports HDR, what would be the reason to choose another codec like DNxHR ?

  3) Any ideas on what could be the cause of the colors not transcoding correctly from the H.264 source file to the DNxHR 444 10 bits one ? The command looks ok to me, but FFprobe output says the DNxHR video is BT709, while with the source file it says BT2020. Like I said, apparently there’s something wrong with the transcoding process regarding metadata or color space.

  4) I haven’t tried to transcode the source file to a DNxHR 444 10 bits video file, but in a MOV container. I don’t know how this works internally, but maybe the color issue has something to do with the container metadata or something. I may try this if there’s not another suggestion (transcoding this kind of files, as you know, takes time, so I’ll wait for some ideas first).

  NOTE : I tried to transcode the source file in the same way (DNxHR 444, 10 bits, etc) with Adobe Media Encoder 2020 and the result was the same, with colors messed up and FFprobe saying the video is BT709. Also tried transcoding to DNxHR HQX profile (10 bits), same result.

  Any help would be greatly appreciated.

  Thanks in advance.

• Evolution #4753 : Styles du privé : listes d’objets (suite des boîtes et des formulaires)

  4 mai 2021

  Un point étape.
  Cette fois-ci j’aimerais bien un historique pas trop cassé, donc discussion avant de balancer du code.
  Maintenant les captures ne sont plus des maquettes, mais du vrai code.

  Emballage extérieur¶

  Donc pour la partie « emballage extérieur », les boîtes, formulaires et listes sont unifiés et réutilisent les mêmes variables CSS.
  Elles ont toutes une variante .mini pour tout ressérer. Cette variante est automatiquement appliquée en certains endroits (dans les colonnes, etc.).

  

  Intérieur¶

  Pour l’intérieur, j’ai donc appliqué ces quelques règles :

  • Padding un peu plus grand
  • Plus de largeur fixe, à l’exception de quelques colonnes précises (id, statut, picto)
  • Même taille de texte dans toutes les colonnes, à l’exception des <small></small> éventuels

  Dans les colonnes latérales (.lat), toutes les colonnes du tableau sont masquées à l’exception des .principale et de quelques autres choisies à la main (id, statut).

  J’ai testé avec toutes les listes de la dist, il faudra bien continuer à tester avec d’autres cas de figure.

  

  Listes, formulaires et +¶

  Le sujet des listes objets-lies et objets-associer m’a amené à déborder un peu du sujet initial. Mais tout est un peu lié, un sujet en amène un autre.

  Donc ces 2 listes sont utilisées dans le formulaire editer_liens, j’en ai profité pour essayer de le remettre d’aplomb.
  Là j’ai vu qu’avec l’apparence par défaut (bordure grise + fond blanc), quand plusieurs formulaires de liens se suivaient, on avait du mal à voir où finissait l’un et où commençait l’autre (pas de capture, croyez moi sur parole :).
  En mettant un fond gris, on les distingue beaucoup mieux.
  Et j’ai bien insisté quand ils sont "dépliés", pour distinguer les 2 zones.

  

  

  Mais ça a également un autre avantage : en scannant la fiche objet dans son ensemble, on voit mieux où commence le « vrai » contenu de l’objet, par rapport aux bidules de configuration (date, liens, etc.).
  D’abord les formulaires et autres sur fond gris, puis ensuite le texte de l’objet.

  Donc je pense qu’on pourrait généraliser ça : au lieu de dire « les formulaires editer_liens sont sur fond gris », on pourrait étendre à « tous les formulaires ajoutés par afficher_milieu sont sur fond gris ». Ça reste une règle graphique assez légère, normalement ça ne devrait pas poser de problème avec les formulaires à cet endroit.
  Le problème c’est qu’actuellement il n’y a aucun moyen de cibler en CSS ce qui est ajouté par affiche_milieu, il faut encapsuler tout ça dans un div.afficher_milieu (ce que j’ai fait pour tester le principe).

  Et donc, la fiche objet dans son ensemble pour illustrer :

  

  Ah, et un test pour le formulaire de traductions :