Recherche avancée

Sur d’autres sites (6067)

• Why I became a HTML5 co-editor

  15 août 2012, par silvia

  A few weeks ago, I had the honor to be appointed as part of the editorial team of the W3C HTML5 specification.

  Since Ian Hickson had recently decided to focus solely on editing the WHATWG HTML living standard specification, the W3C started looking for other editors to take the existing HTML5 specification to REC level. REC level is what other standards organizations call a “ratified standard”.

  But what does REC level really mean for HTML ?

  In my probably somewhat subjective view, recommendation level means that a snapshot is taken of the continuously evolving HTML spec, which has a comprehensive feature set, that is implemented in a cross-browser interoperable way, has a complete test set for the features, and has received wide review. The latter implies that other groups in the W3C have had a chance to look at the specification and make sure it satisfies their basic requirements, which include e.g. applicability to all users (accessibility, internationalization), platforms, and devices (mobile, TV).

  Basically it means that we stop for a “moment”, take a deep breath, polish the feature set that we’ve been working on this far, and make sure we all agree on it, before we get back to changing the world with cool new stuff. In a software project we would call it a release branch with feature freeze.

  Now, as productive as that may sound for software – it’s not actually that exciting for a specification. Firstly, the most exciting things happen when writing new features. Secondly, development of browsers doesn’t just magically stop to get the release (REC) happening. And lastly, if we’ve done our specification work well, there should be only little work to do. Basically, it’s the unthankful work of tidying up that we’re looking at here.

  So, why am I doing it ? I am not doing this for money – I’m currently part-time contracting to Google’s accessibility team working on video accessibility and this editor work is not covered by my contract. It wasn’t possible to reconcile polishing work on a specification with the goals of my contract, which include pushing new accessibility features forward. Therefore, when invited, I decided to offer my spare time to the W3C.

  I’m giving this time under the condition that I’d only be looking at accessibility and video related sections. This is where my interest and expertise lie, and where I’m passionate to get things right. I want to make sure that we create accessibility features that will be implemented and that we polish existing video features. I want to make sure we don’t digress from implementations which continue to get updated and may follow the WHATWG spec or HTML.next or other needs.

  I am not yet completely sure what the editorship will entail. Will we look at tests, too ? Will we get involved in HTML.next ? This far we’ve been preparing for our work by setting up adequate version control repositories, building a spec creation process, discussing how to bridge to the WHATWG commits, and analysing the long list of bugs to see how to cope with them. There’s plenty of actual text editing work ahead and the team is shaping up well ! I look forward to the new experiences.

• Handle AVID MJPEG streams directly in the MJPEG decoder.

  12 décembre 2020, par Anton Khirnov

  Handle AVID MJPEG streams directly in the MJPEG decoder.
  AVID streams - currently handled by the AVRN decoder - can be (depending
  
  on extradata contents) either MJPEG or raw video. To decode the MJPEG
  
  variant, the AVRN decoder currently instantiates a MJPEG decoder
  
  internally and forwards decoded frames to the caller (possibly after
  
  cropping them).
  This is suboptimal, because the AVRN decoder does not forward all the
  
  features of the internal MJPEG decoder, such as direct rendering.
  
  Handling such forwarding in a full and generic manner would be quite
  
  hard, so it is simpler to just handle those streams in the MJPEG decoder
  
  directly.
  The AVRN decoder, which now handles only the raw streams, can now be
  
  marked as supporting direct rendering.
  This also removes the last remaining internal use of the obsolete
  
  decoding API.
  

  • [DH] configure
  • [DH] libavcodec/avrndec.c
  • [DH] libavcodec/mjpegdec.c
  • [DH] libavcodec/version.h
  • [DH] libavformat/avidec.c
  • [DH] libavformat/isom_tags.c
  • [DH] tests/fate/video.mak

• ffmpeg : precisely cut a video

  19 octobre 2019, par Santhosh Yedidi

  I am tring to cut a video in linux OS

  $ ffmpeg -i dhol.mkv 
  
  ffmpeg version n4.1.2 Copyright (c) 2000-2019 the FFmpeg developers
  
    built with gcc 8.2.1 (GCC) 20181127
  
    configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libjack --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-nvdec --enable-nvenc --enable-omx --enable-shared --enable-version3
  
    libavutil      56. 22.100 / 56. 22.100
  
    libavcodec     58. 35.100 / 58. 35.100
  
    libavformat    58. 20.100 / 58. 20.100
  
    libavdevice    58.  5.100 / 58.  5.100
  
    libavfilter     7. 40.101 /  7. 40.101
  
    libswscale      5.  3.100 /  5.  3.100
  
    libswresample   3.  3.100 /  3.  3.100
  
    libpostproc    55.  3.100 / 55.  3.100
  
  Input #0, matroska,webm, from 'dhol.mkv':
  
    Metadata:
  
      ENCODER         : Lavf58.20.100
  
    Duration: 00:03:56.18, start: -0.007000, bitrate: 2688 kb/s
  
      Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv, bt709/unknown/unknown), 1920x1080, SAR 1:1 DAR 16:9, 30 fps, 30 tbr, 1k tbn, 1k tbc (default)
  
      Metadata:
  
        DURATION        : 00:03:56.167000000
  
      Stream #0:1(eng): Audio: opus, 48000 Hz, stereo, fltp (default)
  
      Metadata:
  
        DURATION        : 00:03:56.181000000

  I was trying to precisely cut the video file :

  But using ffmpeg I was not successfull. It cuts from the nearest key frames to the given start time

  ffmpeg -y -i dhol.mkv -ss $shift   -t $duration -c:v copy -an output.mkv

  ONE OF THE REASONS HERE IS H.264 Video format (YUV420p vs YUV420sp). I am using -c:v copy so it has to use the same format YUV420p, so it has to start from nearest keyframe

  Now the only reliable software that i can fully depend if avidemux.

  Even in that i have to select

  video-codec: MJPEG
  
  audio-codec: vorbis

  But the cut video size will be large.

  I tried in avidemux

  video-codec: copy
  
  audio-codec: copy

  It will cut from nearest keyframe than precisely.

  One conclusion :
  So irrespective of ffmpeg or avidemux, the output video format yuv420p will not allow precise formatting

  Only option currently possible :

  Using avidemux and with

  video-codec: MJPEG
  
  audio-codec: vorbis

  Cons :

  1) bigger video size.
  
  2) no proper command line examples available for avidemux to do the same as gui does

  I tried command line in avidemux :

  avidemux3_cli --video-codec MJPEG --audio-codec AAC --output-format AVI --load dhol.mkv --begin 137.633 --end 141.334 --save dhol2.mkv

  It tries to convert the whole file rather than from the start to end time

  My requirement :
  I want to do it command line.

  I didnt try with ffmpeg (with video codec : MJPEG and audio : vorbis). I never saw any example

  How to precisely cut a video (even the output format can be different (like MJPEG instead of yuv420p, and also bigger sizes, its ok) using command line