Recherche avancée

Sur d’autres sites (6574)

• Remux and segment only parts of a video file without difference in output

  20 juin 2013, par Christian P.

  I have a working program built on top of libav (alternatively ffmpeg - expertise is either is useful here).

  It takes an mp4 video, encoded with h264 video / AAC audio, and remuxes it to MPEG TS and segments it into X second chunks. It is analogous to the following ffmpeg command :

  ffmpeg -y -i video.mp4 -c:a copy -bsf:a aac_adtstoasc -c:v copy -bsf:v h264_mp4toannexb -flags -global_header -map 0 -f segment -segment_time 10 -segment_list playlist.m3u8 -segment_format mpegts chunk_%03d.ts

  The reason I am not using the command-line, is that I wish to generate only a subset of the segments. So if a video results in 10 segments of between 8 and 12 seconds (the segments are never exactly the desired length due to keyframes), I might wish to generate segments 3-7 at a later time.

  The complete code for my program can be found here.

  I use av_read_frame to read every frame from the source file, remux (including a bitfilter process) and write to output file. Once the duration since the last output becomes close/greater than the desired segment length, I flush the output file, close it, open the next segment and continue.

  I have tried altering the code to do an av_seek_frame to the end of the first segment and start from there (I also attempted to start at the end of the 2nd and 3rd segment). The new segments are the same length (in seconds and pts), but have a different size than the comparable segments from the full runthrough (within a few kilobytes) - the starting segment (whether it's the 2nd, 3rd or other) also shows as having 2 packets LESS than the comparable segment from previously.

  I assumed that av_seek_frame would give me an exact match as if I had manually done a loop with av_read_frame up to that frame, but it seems like it's not the case.

  What I wish for :

  • A way to "fast-forward" in the file to a specific (not approximate) point in the file.
  • To write from that point forward and have the output be completely identical to the output a full run provides (same size, same length, same exact bytes).

• Making Sure The PNG Gets There

  14 juin 2013, par Multimedia Mike — General

  Rewind to 1999. I was developing an HTTP-based remote management interface for an embedded device. The device sat on an ethernet LAN and you could point a web browser at it. The pitch was to transmit an image of the device’s touch screen and the user could click on the picture to interact with the device. So we needed an image format. If you were computing at the time, you know that the web was insufferably limited back then. Our choice basically came down to GIF and JPEG. Being the office’s annoying free software zealot, I was championing a little known up and coming format named PNG.

  So the challenge was to create our own PNG encoder (incorporating a library like libpng wasn’t an option for this platform). I seem to remember being annoyed at having to implement an integrity check (CRC) for the PNG encoder. It’s part of the PNG spec, after all. It just seemed so redundant. At the time, I reasoned that there were 5 layers of integrity validation in play.

  I don’t know why, but I was reflecting on this episode recently and decided to revisit it. Here are all the encapsulation layers of a PNG file when flung over an ethernet network :

  
  
  

  So there are up to 5 encapsulations for the data in this situation. At the innermost level is the image data which is compressed with the zlib DEFLATE method. At first, I thought that this also had a CRC or checksum. However, in researching this post, I couldn’t find any evidence of such an integrity check. Further, I don’t think we bothered to compress the PNG data in this project long ago. It was a small image, monochrome, and transferring via LAN, so the encoder could get away with signaling uncompressed data.

  The graphical data gets wrapped up in a PNG chunk and all PNG chunks have a CRC. To transmit via the network, it goes into a TCP frame, which also has a checksum. That goes into an IP packet. I previously believed that this represented another integrity check. While an IP frame does have a checksum, the checksum only covers the IP header and not the payload. So that doesn’t really count towards this goal.

  Finally, the data gets encapsulated into an ethernet frame which has — you guessed it — a CRC.

  I see that other link layer protocols like PPP and wireless ethernet (802.11) also feature frame CRCs. So I guess what I’m saying is that, if you transfer a PNG file over the network, you can be confident that the data will be free of any errors.

• A random pixel on a keyframe. (ffmpeg)

  5 juin 2013, par Chris Russo

  Hello folks of SO !

  We're trying to do some very small and simple code in PHP to generate a variation of a video, using always the same file.

  The script would have to make a small pixel mark, on random or specific frame of the video file, and this would have to be streamed in real time.

  Here's some pseudo code to explain my idea :

  $frame = $_GET[frame];
  
  $videofile = 'video.avi';
  
  
  
  make_random_red_pixel_mark($videofile, $frame);

  Does anyone know if this is possible using ffmpeg ? As well, it is of extreamly importance for us, to execute this procedure as fast as possible.

  A solution that would imply reprocessing the whole video, won't be useful for our purposes. It should be something like a closed caption, or a quick image / overlay filter that could be applied without an entire video reprocessing. As well, we can't put the overlay using Javascript nor any HTML approach, since the actual manipulation has to be on the video file itself.

  The quality, and framerate of the original video, should be kept intact. Perhaps some other PHP module or software that could be execute from PHP using an exec() ?

  Any recommendation ?

  Thanks in advance !!
  Chris C. Russo

  More information :

  1) It's possible for us to apply this procedure on any frame we want to, so we could use a "keyframe" in order to avoid the decoding and reencoding of an entire GOP.

  2) As previously stated, the video stream would have to flow in real time.