Recherche avancée

Sur d’autres sites (8964)

• Download encrypted TS files from video stream

  8 janvier 2021, par albertma789

  Following this post, I usually download transport stream (.ts) files by using the browser's developer console to find the URLs of the .ts files and then I use wget to download them. After that I use the ffmpeg -f concat method to combine them into an mp4 file.

  



  Recently I come across a site that streams videos and I used the same method to download all the .ts files. The site is here. After I downloaded all the individual .ts files, I use ffmprobe to check the file format but realized the .ts files cannot be understood by ffmpeg/ffmprobe. While the site uses http (not https) I thought the streams are not encrypted so I tried to open the .ts file in an hex editor but I don't know what format it is (but they don't look like zip/gz). My question is : are the transport steams encrypted ? If yes, is there a way to decrypt them ? If not ? Can anyone point me to the right direction such that I can make ffmpeg understand them ?

  



  An example transport stream (first & second) are here and here but the link might expire in a bit. In that case you will need to open the site in developer console to find the updated link to the .ts files.

  



  The site uses JW Player 8.0.0

  


• CCTV DVR recovery

  5 juin 2014, par bitmadmax

  I need to recover footage from one of these unbranded CCTV DVR units. I am unable to gain access to the unit via a password, factory reset or backdoor, which would otherwise have let me "export" the footage.

  So I have pulled the hard disk and made a copy of it. The original unit is Linux-based which ran off a chip, and an EXT filesystem laid down on the hard disk itself. There is one partition which appears to contain the "raw" CCTV footage.

  The hex structure appears as though each frame begins with 00dcH264, 01dcH264, 10dcH264 and so on... I think the 00, 01, 10 etc refers to the channel/camera input number. The hex contents after the H264 portion appears completely random, of variable length and has no signature, and is followed immediately with the next xxdcH264 header.

  When I use ffprobe across the entire raw footage partition, it is only detecting the 1 video stream. I can use ffmpeg to "force" it to read it in as H.264 and dump it out into an MP4 file that I can play. However, this gives me the problem that the footage as an individual file is quite "noisy" and has frames from each channel appearing randomly.

  Is there anyway I could maybe separate out the footage into say a file for each channel ? I am not a great programmer so something as simple as possible would be ideal. I did note that ffprobe determined that some of the frames were of different resolution - it is likely that the different channels recorded their image at different dimensions, I just wondered if another way might be to get ffprobe/ffmpeg to output frames based on their image dimensions perhaps ?

  EDIT : sample hex below :

  Offset      0  1  2  3  4  5  6  7   8  9 10 11 12 13 14 15
  
  00000000   32 31 64 63 48 32 36 34  76 08 00 00 00 00 00 00   21dcH264v       
  
  00000016   1E 8B 77 07 6A 00 00 00  00 00 00 01 61 FC 03 51    ‹w j       aü Q
  
  00000032   42 83 FC C5 C6 BD 50 63  5F 37 68 B6 B5 B8 4F E0   BƒüÅƽPc_7h¶µ¸Oà
  
  00000048   2E 74 B8 FF BB BD 70 1C  DE 1E 7A 8C 0F            .t¸ÿ»½p Þ zŒ 

  (variable length)....

  Offset      0  1  2  3  4  5  6  7   8  9 10 11 12 13 14 15
  
  00000000   D3 30 59 01 FA 98 08 A0  0A 27 01 49 19 C1 0C 89   Ó0Y ú˜   ' I Á ‰
  
  00000016   83 AC 6B 28 03 8D 92 29  38 18 BA 95 82 B3 BA C6   ƒ¬k(  ’)8 º•‚³ºÆ
  
  00000032   33 0A 74 10 1A D5 89 3B  90 A0 19 1F A9 93 00 10   3 t  Õ‰;    ©“  
  
  00000048   92 AA 70 32 31 64 63 48  32 36 34                  ’ªp21dcH264

• movenc : Add a flag for indicating a discontinuous fragment

  20 novembre 2014, par Martin Storsjö

  movenc : Add a flag for indicating a discontinuous fragment
  This allows creating a later mp4 fragment without sequentially
  
  writing the earlier ones before (when called from a segmenter).
  Normally when writing a fragmented mp4 file sequentially, the
  
  first timestamps of a fragment are adjusted to match the
  
  end of the previous fragment, to make sure the timestamp is the
  
  same, even if it is calculated as the sum of previous fragment
  
  durations. (And for the first packet in a file, the offset of
  
  the first packet is written using an edit list.)
  When writing an individual mp4 fragment discontinuously like this
  
  (with potentially writing the earlier fragments separately later),
  
  there’s a risk of getting a gap in the timeline if the duration
  
  field of the last packet in the previous fragment doesn’t match up
  
  with the start time of the next fragment.
  Using this requires setting -avoid_negative_ts make_non_negative
  
  (or -avoid_negative_ts 0).
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavformat/movenc.c
  • [DH] libavformat/movenc.h