Recherche avancée

Sur d’autres sites (7517)

• 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.

• Why I became a HTML5 co-editor

  1er janvier 2014, 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.

• When using the exiftool `-v` command, Rotation property is misisng

  4 juin 2023, par SShah

  I am still not certain if this is the right place to ask, I am currently attempting to backup 60gb+ size videos on my phone to pc, but while doing so I am also trying to leverage FFMPEG and/or exiftool to convert the files to HVEC format (for reduced file size) and to ensure all relevant metadata is copied over from the source file to the converted file.

  


  My question to be specific is related to exiftool in particular where I noticed a discrepancy and was wondering if someone can assist me :

  


  I am currently converting the video files using the following ffmpeg command :

  


  ffmpeg -hwaccel qsv -i "VID_20220629_201116.mp4" -crf 27 -movflags use_metadata_tags -c copy -c:v hevc_qsv -global_quality 25 -vf scale_qsv=1920:1080 -c:a copy -preset slow "VID_20220629_201116_h265 (2).mp4"

  


  This does convert the file to H265 but the final file only copies over some datestamps and misses to add/update additional related tags (such as gps) that my phone has added to the source file. But more annoyingly its not detecting the orientation of the source video (which is in portrait) and producing an output in landscape.

  


  I have then written the following python script where I use the the PyExifTool module to try and update the file with any missing tags from the original file.

  


  import exiftool
from pprint import pprint
import json
from datetime import datetime

video = exiftool.ExifTool()

# Get the path to the file
source_file_path = r"\VID_20220629_201116.mp4"
destination_file_path  = r"\VID_20220629_201116_h265 (2).mp4"

print(f"Source File Path: {source_file_path}")
print(f"Destination File Path: {destination_file_path}\n")

with exiftool.ExifToolHelper() as et:
    source_file_metadata: list = et.get_tags(source_file_path, "All")[0]   
    destination_file_metadata: list = et.get_tags(destination_file_path, "All")[0]
    
    keys_to_check = [];
    source_file_tag_names = source_file_metadata.keys()
    destination_file_tag_names = destination_file_metadata.keys()
    tags_to_update = {}
    
    with open("source.json", "w") as f:
        f.write(json.dumps(source_file_metadata, indent=4, sort_keys=True))
        # pprint(source_file_metadata, f)
    
    with open("destination.json", "w") as f:
        f.write(json.dumps(destination_file_metadata, indent=4, sort_keys=True))
        # pprint(destination_file_metadata, f)
    
    for tag in source_file_tag_names:
        if tag not in destination_file_tag_names or "date" in tag.lower():
            keys_to_check.append(tag)
            
            if tag in destination_file_metadata: 
                if destination_file_metadata[tag] == source_file_metadata[tag]:
                    continue
                
            tags_to_update[tag] = source_file_metadata[tag]

    pprint(f"Tags to Update: {tags_to_update}")
    
    if tags_to_update:
        print(et.set_tags(destination_file_path, tags_to_update))


  


  This script compares the destination file, with the source file and updates the destination file with any tags that belong in the source file, but not in the destintation file.

  


  In regards to the orientation issue I have, I noticed that if I manually run the following command in the command line :

  


  exiftool "source_file_name.mp4"

  


  Then in the output it generates, it displays the property Rotation as follows :

  


  Rotation                        : 90

  


  However, this does'nt seem to be captured from my script and therefore I can not see it in the destination file after I run my script. I also suspect this property will help fix my orientation issue that I am currently facing with ffmpeg.

  


  So after looking deeper into exiftool I found that I can add -v to the comamand to display output as variable names :
exiftool -v "source_file_name.mp4"

  


  After running the above command, from the output I see no variable called or associated to attribute Rotation, and this is why I believe my script is unable to apply to the destination file either.

  


  Sorry I understand my description is long, and I appreciate you taking the time to review it, please let me know if there is a way I can map this Rotation value, and/or if you think there is a much better solution for me to map all the metatags from the source file to the converted destination file.

  


  Thank you.