Recherche avancée

Sur d’autres sites (9379)

• The First Problem

  19 janvier 2011, par Multimedia Mike — HTML5

  A few years ago, The Linux Hater made the following poignant observation regarding Linux driver support :

  Drivers are only just the beginning... But for some reason y’all like to focus on the drivers. You know why lusers do that ? Because it just happens to be the problem that people notice first.

  And so it is with the HTML5 video codec debate, re-invigorated in the past week by Google’s announcement of dropping native H.264 support in their own HTML5 video tag implementation. As I read up on the fiery debate, I kept wondering why people are so obsessed with this issue. Then I remembered the Linux Hater’s post and realized that the video codec issue is simply the first problem that most people notice regarding HTML5 video.

  I appreciate that the video codec debate has prompted Niedermayer to post on his blog once more. Otherwise, I’m just munching popcorn on the sidelines, amused and mildly relieved that the various factions are vociferously attacking each other rather than that little project I help with at work.

  Getting back to the "first problem" aspect— there’s so much emphasis on the video codec ; I wonder why no one ever, ever mentions word one about an audio codec. AAC is typically the codec that pairs with H.264 in the MPEG stack. Dark Shikari once mentioned that "AAC’s licensing terms are exponentially more onerous than H.264′s. If Google didn’t want to use H.264, they would sure as hell not want to use AAC." Most people are probably using "H.264" to refer to the entire MPEG/H.264/AAC stack, even if they probably don’t understand what all of those pieces mean.

  Anyway, The Linux Hater’s driver piece continues :

  Once y’all have drivers, the fight will move to the next layer up. And like I said, it’s a lot harder at that layer.

  A few months ago, when I wanted to post the WebM output of my new VP8 encoder and thought it would be a nice touch to deliver it via a video tag, I ignored the video codec problem (just encoded a VP8/WebM file) only to immediately discover a problem at a different layer— specifically, embedding a file using a video tag triggers a full file download when the page is loaded, which is unacceptable from end user and web hosting perspectives. This is a known issue but doesn’t get as much attention, I guess because there are bigger problems to solve first (c.f. video codec issue).

  For other issues, check out the YouTube blog’s HTML5 post or Hulu’s post that also commented on HTML5. Issues such as video streaming flexibility, content protection, fullscreen video, webcam/microphone input, and numerous others are rarely mentioned in the debates. Only "video codec" is of paramount importance.

  But I’m lending too much weight to the cacophony of a largely uninformed internet debate. Realistically, I know there are many talented engineers down in the trenches working to solve at least some of these problems. To tie this in with the Linux driver example, I’m consistently stunned these days regarding how simple it is to get Linux working on a new computer— most commodity consumer hardware really does just work right out of the box. Maybe one day, we’ll wake up and find that HTML5 video has advanced to the point that it solves all of the relevant problems to make it the simple and obvious choice for delivering web video in nearly all situations.

  It won’t be this year.

• When rTorrent finishes, run FFmpeg and convert audio track in mkv to ac-3 5.1

  11 septembre 2021, par miniHessel

  What is the best approach for this ? I saw the following answer, is that still a valid approach ? If so, how do you execute that when a torrent finishes ? I mostly want to convert dts-hd either 5.1 or 7.1. Sometimes also Atmos.

  


• Last bytes of AVPacket

  3 avril 2018, par João Gueifão

  I have been experimenting with FFmpeg libav C libraries to open, read and demux a video file with both video and KLV (key-lengh-value) streams. The data stream is built according to the UAS Datalink Local Metadata Set as per the MISB ST 0601.11 standard.
  At the moment I am able to play the video on a window and dump the KLV metadata on the console just fine. I came to realise that whenever I dump the content of a AVPacket on the console, the last 14 bytes are constant, throughout different video files. I was provided a KLV decoder according to that MISB standard, which is working just fine, but ONLY WHEN I REMOVE THOSE last 14 bytes from every AVPacket data array given by FFmpeg.

  My question is : what are those 14 bytes in the first place ? I could not find them in the video file itself. I inspected the raw binary stream at one of the files and could not find those bytes anywhere. That makes me hypothesise that it is FFmpeg that is computing them itself ?

  Further details

  I discovered the following :

  • for a same video file, the value of those 14 bytes never change ;
  • when switching to a different video file, only the first 2 bytes of those 14 final bytes change ;
  • when I dump the content of a AVPacket corresponding to a video frame, those 14 bytes also are very similar.

  Here are two examples of the different 14 byte strings that I got until so far :

  • FC00 0000 01CE 8C4D 9D10 8E25 E9FE
  • BD00 0000 01CE 8C4D 9D10 8E25 E9FE

  As you may see, they are all very similar.

  Below is an example of the dump of an AVPacket::data array on the console. First we can see the the 16-byte Universal Key for this UAS Datalink Local Data Set, followed by the remaining of the packet, finishing with the mysterious 14-byte footer. I provide newlines just for readability.

  06 0E2B 3402 0B01 010E 0103 0101 0000 00
  
  81 F102 0800 04CA 140D 4323 0B03 1545 5352 495F 4D65 7461 6461 7461 5F43 6F6C 6C65 6374 0406 4E39 3738 3236 0502 F86E 0602 119A 0702 ED0B 0A05 4332 3038 420B 000C 000D 043A 841D A40E 04B5 80F4 A10F 0231 C710 0201 8B11 0200 DE12 04CD 0444 4513 04F1 2666 6614 0400 0000 0015 0400 2037 BB16 0200 0017 043A 8562 8718 04B5 7C46 AC19 0223 811A 02FF BA1B 02FF 551C 0200 6F1D 02FF 801E 0200 451F 0200 A820 02FF 9421 0200 7E2F 0100 302A 0101 0102 0101 0304 2F2F 4341 0400 0500 0602 4341 1510 0000 0000 0000 0000 0000 0000 0000 0000 1602 0005 3801 003B 0846 6972 6562 6972 6441 0101 4808 0000 0000 0000 0000 0102 DA78 
  
  FC00 0000 01CE 8C4D 9D10 8E25 E9FE

  I tried to follow the metadata.c example file on FFmpeg source examples, but it was unhelpful, as it only shows how to leverage the decoding of metadata from streams for which FFmpeg was an appropriate metadata codec. Again, in my case, the data stream is structured according to the UAS Datalink Local Metadata Set, and FFmpeg does not provide an appropriate codec.

  Thank you for your help.