How to decrypt .ts files into separate .ts files with ffmpeg without using a playlist?
Hi, I have a number of .ts files, .m3u8 playlist and a key to decrypt them. The key is a file, not a hexadecimal string. My goal is to decrypt some of these .ts files to analyze them individually. I also obviously don't want to modify the actual video/audio streams in them in any way, just a decryption. I have no problem decrypting them as an .m3u8 playlist into one big .ts or .mp4 file with a simple command like "ffmpeg -allowed_extensions ALL -i chunklist.m3u8 -c copy output.ts", I just use URI=key in the playlist and it works. But I need them to be decrypted into separate files, not one. I could probably just leave only one line in the playlist and decrypt them one by one like this but I want to learn how to do it properly. I tried opening the key file in a hex editor (which is probably a dumb thing to do) and then using the hex value in a command like "ffmpeg -decryption_key {hex_value} -i part1.ts part1.ts" but it gives me the "Invalid data found when processing input" error... So how to do this properly? The ffmpeg documentation wasn't helpful... [Here](https://www.mediafire.com/file/twsn7mdew9aa8lx/test.zip/file) are the files I'm working with in a zip archive. I've included only three of the .ts files there, that should be enough for a test. Any help will be greatly appreciated. Thanks! ~ Red Elephant.
On Mon, Feb 10, 2020 at 10:41 AM Crazy Red Elephant via ffmpeg-user < ffmpeg-user@ffmpeg.org> wrote:
Hi,
I have a number of .ts files, .m3u8 playlist and a key to decrypt them. The key is a file, not a hexadecimal string. My goal is to decrypt some of these .ts files to analyze them individually. I also obviously don't want to modify the actual video/audio streams in them in any way, just a decryption.
I have no problem decrypting them as an .m3u8 playlist into one big .ts or .mp4 file with a simple command like "ffmpeg -allowed_extensions ALL -i chunklist.m3u8 -c copy output.ts", I just use URI=key in the playlist and it works. But I need them to be decrypted into separate files, not one.
I could probably just leave only one line in the playlist and decrypt them one by one like this but I want to learn how to do it properly.
I tried opening the key file in a hex editor (which is probably a dumb thing to do) and then using the hex value in a command like "ffmpeg -decryption_key {hex_value} -i part1.ts part1.ts" but it gives me the "Invalid data found when processing input" error...
So how to do this properly? The ffmpeg documentation wasn't helpful...
[Here](https://www.mediafire.com/file/twsn7mdew9aa8lx/test.zip/file) are the files I'm working with in a zip archive. I've included only three of the .ts files there, that should be enough for a test.
Any help will be greatly appreciated. Thanks!
~ Red Elephant.
You can decrypt single files using "ffmpeg -key (hex key) -iv (hex IV, required) -i crypto+file:/path/to/file.ts"
I only have the key file which is like "5e5852fab5eedf7c6b7a367b1fc140a1" when I open it in a hex editor. What is "hex IV" and where can I get it? ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, February 10, 2020 5:55 PM, Micael Silva <micaelsilva@gmail.com> wrote:
On Mon, Feb 10, 2020 at 10:41 AM Crazy Red Elephant via ffmpeg-user < ffmpeg-user@ffmpeg.org> wrote:
Hi, I have a number of .ts files, .m3u8 playlist and a key to decrypt them. The key is a file, not a hexadecimal string. My goal is to decrypt some of these .ts files to analyze them individually. I also obviously don't want to modify the actual video/audio streams in them in any way, just a decryption. I have no problem decrypting them as an .m3u8 playlist into one big .ts or .mp4 file with a simple command like "ffmpeg -allowed_extensions ALL -i chunklist.m3u8 -c copy output.ts", I just use URI=key in the playlist and it works. But I need them to be decrypted into separate files, not one. I could probably just leave only one line in the playlist and decrypt them one by one like this but I want to learn how to do it properly. I tried opening the key file in a hex editor (which is probably a dumb thing to do) and then using the hex value in a command like "ffmpeg -decryption_key {hex_value} -i part1.ts part1.ts" but it gives me the "Invalid data found when processing input" error... So how to do this properly? The ffmpeg documentation wasn't helpful... Here are the files I'm working with in a zip archive. I've included only three of the .ts files there, that should be enough for a test. Any help will be greatly appreciated. Thanks! ~ Red Elephant.
You can decrypt single files using "ffmpeg -key (hex key) -iv (hex IV, required) -i crypto+file:/path/to/file.ts"
ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
Hi, Micael. I tried your command like this: "ffmpeg -key 5e5852fab5eedf7c6b7a367b1fc140a1 -iv 00000000000000000000000000000000 -i crupto+file:part0.ts part0-decrypted.ts" and got the following errors: [NULL @ 000002c5c712f980] missing picture in access unit with size 8 [h264 @ 000002c5c7a50100] no frame! Error while decoding stream #0:1: Invalid data found when processing input The result file opens but is very low quality and missing some frames at the beginning. Looks like FFmpeg does something wrong here... ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, February 10, 2020 5:55 PM, Micael Silva <micaelsilva@gmail.com> wrote:
You can decrypt single files using "ffmpeg -key (hex key) -iv (hex IV, required) -i crypto+file:/path/to/file.ts"
ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
On 2020-02-10T16:55:04+0100, Micael Silva <micaelsilva@gmail.com> wrote:
You can decrypt single files using "ffmpeg -key (hex key) -iv (hex IV, required) -i crypto+file:/path/to/file.ts" Hmm, never knew this was possible. Very interesting. Thanks, Micael!
-- Reino
On Mon, Feb 10, 2020 at 13:40:59 +0000, Crazy Red Elephant via ffmpeg-user wrote:
I have a number of .ts files, .m3u8 playlist and a key to decrypt them. The key is a file, not a hexadecimal string. My goal is to decrypt some of these .ts files to analyze them individually. I also obviously don't want to modify the actual video/audio streams in them in any way, just a decryption.
I had to google my way into this, but have a solution: This AES encryption is on the outmost layer. In other words, no demuxing has to be done before decrypting. You can just apply straight AES decryption onto the input segments, without using ffmpeg. You already figured out the key from the keyfile. As your m3u8 has no "IV" section, I assumed your encryption uses no such initialization vector. I found that the openssl command line tool can do this decrption: $ openssl aes-128-cbc -d -nosalt -K 5e5852fab5eedf7c6b7a367b1fc140a1 -iv 0 -in part0.ts -out part0.dec.ts I did this for each segment (in a shell loop obviously), and got the desired results. The decrypted segments now play exactly like your encrypted playlist.
So how to do this properly? The ffmpeg documentation wasn't helpful...
As far as I can tell, the HLS demuxer handles key files, but the command line tool itself only takes actual decryption keys (and IVs), not files. And I didn't manage to decrypt the individual segments with ffmpeg, even with use of the key values on the command line.
[Here](https://www.mediafire.com/file/twsn7mdew9aa8lx/test.zip/file) are the files I'm working with in a zip archive. I've included only three of the .ts files there, that should be enough for a test.
Appreciated. That was good for testing. Hope this helps, Moritz
This works, Moritz, thank you. However, for some reason it works only for the part0 file, two others don't open in Windows Media Player after decryption. That's weird... What's also interesting is that there's about 17 KB difference in size between the part0 file decrypted with openssl (3,476 KB, which is 16 bytes less than the original encrypted one) and part0 decrypted from m3u8 (3,496 KB). Do you have any idea why it's like that? Another thing is that I'm getting a "hex string is too short, padding with zero bytes to length" message but I suppose is fine since we use -iv 0... ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, February 10, 2020 9:18 PM, Moritz Barsnick <barsnick@gmx.net> wrote:
On Mon, Feb 10, 2020 at 13:40:59 +0000, Crazy Red Elephant via ffmpeg-user wrote:
I have a number of .ts files, .m3u8 playlist and a key to decrypt them. The key is a file, not a hexadecimal string. My goal is to decrypt some of these .ts files to analyze them individually. I also obviously don't want to modify the actual video/audio streams in them in any way, just a decryption.
I had to google my way into this, but have a solution:
This AES encryption is on the outmost layer. In other words, no demuxing has to be done before decrypting. You can just apply straight AES decryption onto the input segments, without using ffmpeg.
You already figured out the key from the keyfile. As your m3u8 has no "IV" section, I assumed your encryption uses no such initialization vector.
I found that the openssl command line tool can do this decrption:
$ openssl aes-128-cbc -d -nosalt -K 5e5852fab5eedf7c6b7a367b1fc140a1 -iv 0 -in part0.ts -out part0.dec.ts
I did this for each segment (in a shell loop obviously), and got the desired results. The decrypted segments now play exactly like your encrypted playlist.
So how to do this properly? The ffmpeg documentation wasn't helpful...
As far as I can tell, the HLS demuxer handles key files, but the command line tool itself only takes actual decryption keys (and IVs), not files. And I didn't manage to decrypt the individual segments with ffmpeg, even with use of the key values on the command line.
Here are the files I'm working with in a zip archive. I've included only three of the .ts files there, that should be enough for a test.
Appreciated. That was good for testing.
Hope this helps, Moritz
ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
On Mon, Feb 10, 2020 at 21:16:36 +0000, Crazy Red Elephant via ffmpeg-user wrote:
This works, Moritz, thank you. However, for some reason it works only for the part0 file, two others don't open in Windows Media Player after decryption. That's weird...
Well, ffmpeg parses the individual decrpypted segments just fine, so *shrug*. I can only guess that when segmenting, they weren't segmented at MPEG-TS packet boundaries, or something like that.
What's also interesting is that there's about 17 KB difference in size between the part0 file decrypted with openssl (3,476 KB, which is 16 bytes less than the original encrypted one) and part0 decrypted from m3u8 (3,496 KB). Do you have any idea why it's like that?
The explanation for the 16 bytes is probably padding (for AES). I'm somewhat new to this, so feel free to correct me. ;-) What do you mean with "part0 decrypted from m3u8"? When using ffmpeg to decrypt via m3u8? Well, you need to consider that "ffmpeg -c copy" does demux and remux, and ffmpeg's MPEG-TS muxer does not (cannot) copy all the properties of the original container. It's simply a different file, though the contained multimedia streams should be identical.
Another thing is that I'm getting a "hex string is too short, padding with zero bytes to length" message but I suppose is fine since we use -iv 0...
Probably. My openssl-1.1.0i didn't care. Cheers, Moritz
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, February 11, 2020 12:26 AM, Moritz Barsnick <barsnick@gmx.net> wrote:
Well, ffmpeg parses the individual decrpypted segments just fine, so shrug. I can only guess that when segmenting, they weren't segmented at MPEG-TS packet boundaries, or something like that.
I tried what Micael suggested for the IV values and it worked. I used the next command for part1 file for example: "openssl aes-128-cbc -d -nosalt -K 5e5852fab5eedf7c6b7a367b1fc140a1 -iv 00000000000000000000000000000001 -in part1.ts -out part1.dec.ts" By the way, when I mux the decrypted .ts parts into one .ts or .mp4 I get lots of "Non-monotonous DTS in output stream 0:0" errors which is another issue I still can't figure out a solution for... But since it's kinda off-topic, I think I will ask it in a new thread :-)
What do you mean with "part0 decrypted from m3u8"? When using ffmpeg to decrypt via m3u8? Well, you need to consider that "ffmpeg -c copy" does demux and remux, and ffmpeg's MPEG-TS muxer does not (cannot) copy all the properties of the original container. It's simply a different file, though the contained multimedia streams should be identical.
Yes, when I use ffmpeg to decrypt via m3u8 with only that one file in it...
On Tuesday, February 11, 2020 12:26 AM, Moritz Barsnick <barsnick@gmx.net> wrote:
Well, ffmpeg parses the individual decrpypted segments just fine, so shrug. I can only guess that when segmenting, they weren't segmented at MPEG-TS packet boundaries, or something like that.
I tried what Micael suggested for the IV values and it worked. I used the next command for part1 file for example:
"openssl aes-128-cbc -d -nosalt -K 5e5852fab5eedf7c6b7a367b1fc140a1 -iv 00000000000000000000000000000001 -in part1.ts -out part1.dec.ts"
By the way, when I mux the decrypted .ts parts into one .ts or .mp4 I get lots of "Non-monotonous DTS in output stream 0:0" errors which is another issue I still can't figure out a solution for... But since it's kinda off-topic, I think I will ask it in a new thread :-)
The IV, when not right, in reality doesn't prevent decryption but makes the output file loop arround itself with parts of the end of the file ending up on the beginning. The "Non-monotonous DTS" on MPEGTS usually happens when the streams starts without some keyframe, makes me think that somehow the IV is wrong therefore the file maybe is looping arround. Did you copy the M3U8 list right? EXT-X-MEDIA-SEQUENCE is the same and there is no IV on the EXT-X-KEY tag?
Yes, Micael, EXT-X-MEDIA-SEQUENCE is the same and there was no IV originally. The only change I did was downloading the key file from the remote server because originally m3u8 had URI={url}. But I believe it doesn't matter anyway because even if I let ffmpeg download everything rather than using files on my computer, the DTS warnings are still there. Also, I don't think the DTS issue is a result of this because I have another example where m3u8's structure is exactly the same but no DTS warnings appear and there are no dropping frames in the result file either. You can find the files from this example [here](https://www.mediafire.com/file/dg2f4l0hdaczq6z/test3.zip/file). I tried to compare these files to the files that give me the DTS warnings in DVBinspector but haven't found anything suspicious, however I'm by no means an expert in this and more likely missed something... ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, February 12, 2020 1:31 AM, Micael Silva micaelsilva@gmail.com wrote:
On Tuesday, February 11, 2020 12:26 AM, Moritz Barsnick barsnick@gmx.net wrote:
Well, ffmpeg parses the individual decrpypted segments just fine, so shrug. I can only guess that when segmenting, they weren't segmented at MPEG-TS packet boundaries, or something like that.
I tried what Micael suggested for the IV values and it worked. I used the next command for part1 file for example: "openssl aes-128-cbc -d -nosalt -K 5e5852fab5eedf7c6b7a367b1fc140a1 -iv 00000000000000000000000000000001 -in part1.ts -out part1.dec.ts" By the way, when I mux the decrypted .ts parts into one .ts or .mp4 I get lots of "Non-monotonous DTS in output stream 0:0" errors which is another issue I still can't figure out a solution for... But since it's kinda off-topic, I think I will ask it in a new thread :-)
The IV, when not right, in reality doesn't prevent decryption but makes the output file loop arround itself with parts of the end of the file ending up on the beginning. The "Non-monotonous DTS" on MPEGTS usually happens when the streams starts without some keyframe, makes me think that somehow the IV is wrong therefore the file maybe is looping arround. Did you copy the M3U8 list right? EXT-X-MEDIA-SEQUENCE is the same and there is no IV on the EXT-X-KEY tag? ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
Nice, I wasn't aware of that, and hadn't found the hlsdec code supporting this. On the other hand, I obviously successfully decrypted each segment with iv=0. *shrug* (again) The IV is XORed with the input before encryption, and the decrypted output is XORed with the IV to get the final result. Since in this case we are starting with a 0 value for the IV I suppose it’s possible you might get away with using 0, especially for the first few segments and get usable output.
Yes, Micael, EXT-X-MEDIA-SEQUENCE is the same and there was no IV originally. The only change I did was downloading the key file from the remote server because originally m3u8 had URI={url}. But I believe it doesn't matter anyway because even if I let ffmpeg download everything rather than using files on my computer, the DTS warnings are still there.
Also, I don't think the DTS issue is a result of this because I have another example where m3u8's structure is exactly the same but no DTS warnings appear and there are no dropping frames in the result file either.
You can find the files from this example [here](https://www.mediafire.com/file/dg2f4l0hdaczq6z/test3.zip/file). I tried to compare these files to the files that give me the DTS warnings in DVBinspector but haven't found anything suspicious, however I'm by no means an expert in this and more likely missed something…
Can you upload an example where you do get DTS warnings? This example decrypted and concatenated fine, but I’m not sure if it was a working example you provided for reference or the one you are having trouble with. https://media.kumowoon1025.com/videos/test3.ts <https://media.kumowoon1025.com/videos/test3.ts> I’m not sure if my earlier reply to your other thread went through, but that also decrypted/concatenated with no issues, except for the fact that it was cut off somewhat arbitrarily, and it complains of a missing frame at the end, but no DTS errors on either one, just a warning about initial timestamps not being set for the timed metadata “stream” which isn’t unusual. https://media.kumowoon1025.com/videos/test.ts <https://media.kumowoon1025.com/videos/test.ts>
Hi Ted, test3.ts (the river video) is the working example I provided for reference. test.ts (the train video) is the one I'm having troubles with. I'm getting these DTS warnings when I remux the .ts parts of the train video example (decrypted or not prior to remuxing - doesn't matter) as m3u8 file into one .ts or straight into .mp4 (by using a command like "ffmpeg -allowed_extensions ALL -i chunklist.m3u8 -c copy output.mp4") Please check my other thread for the console output. I'm NOT getting these DTS warnings for the test3 .ts parts (the river video). If I concatenate the .ts parts into one .ts file prior to remuxing, there are no those DTS warnings, however the resulted .mp4 file like I said has 2 dropped frames at the beginning, is 1 second longer than .ts and has 30.05 fps instead of 29.97 for some reason. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, February 12, 2020 5:16 PM, Ted Park <kumowoon1025@gmail.com> wrote:
Can you upload an example where you do get DTS warnings? This example decrypted and concatenated fine, but I’m not sure if it was a working example you provided for reference or the one you are having trouble with. https://media.kumowoon1025.com/videos/test3.ts https://media.kumowoon1025.com/videos/test3.ts
I’m not sure if my earlier reply to your other thread went through, but that also decrypted/concatenated with no issues, except for the fact that it was cut off somewhat arbitrarily, and it complains of a missing frame at the end, but no DTS errors on either one, just a warning about initial timestamps not being set for the timed metadata “stream” which isn’t unusual. https://media.kumowoon1025.com/videos/test.ts https://media.kumowoon1025.com/videos/test.ts
ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
I'm getting these DTS warnings when I remux the .ts parts of the train video example (decrypted or not prior to remuxing - doesn't matter) as m3u8 file into one .ts or straight into .mp4 (by using a command like "ffmpeg -allowed_extensions ALL -i chunklist.m3u8 -c copy output.mp4") The DTS warnings are coming from stream 0, which is the timed id3 “stream” and they are not errors. The ID3 packets may be emitted sporadically, and non-monotously increasing DTS isn’t a problem.
If I concatenate the .ts parts into one .ts file prior to remuxing, there are no those DTS warnings, however the resulted .mp4 file like I said has 2 dropped frames at the beginning, is 1 second longer than .ts and has 30.05 fps instead of 29.97 for some reason.
I’m not able to reproduce the frame drops you mentioned, unless you mean the drops on playback? Each segment has 120 frames, and when I concat using cat or ffmpeg’s hls demuxer, the result has 360 frames, as expected. If you are talking about the drops when you play the file, those are probably the duplicate frames at the segment boundaries that are being purposely skipped. Add the -noframedrop option in ffplay to force no frame drops, though that is probably not the playback behavior you want. Here are a list of steps I took to test. % mkdir decrypted % openssl aes-128-cbc -d -K 5e5852fab5eedf7c6b7a367b1fc140a1 -iv 00000000000000000000000000000000 -in part0.ts -out decrypted/part0.ts % openssl aes-128-cbc -d -K 5e5852fab5eedf7c6b7a367b1fc140a1 -iv 00000000000000000000000000000001 -in part1.ts -out decrypted/part1.ts % openssl aes-128-cbc -d -K 5e5852fab5eedf7c6b7a367b1fc140a1 -iv 00000000000000000000000000000002 -in part2.ts -out decrypted/part2.ts % cat decrypted/part0.ts decrypted/part1.ts decrypted/part2.ts > decrypted/cat.ts % grep -v '#EXT-X-KEY' chunklist.m3u8 > decrypted/chunklist.m3u8 % ffmpeg -i decrypted/chunklist.m3u8 -c copy decrypted/muxed.mp4 % ffmpeg -i decrypted/chunklist.m3u8 -c copy decrypted/muxed.ts % ffmpeg -allowed_extensions ALL -i chunklist.m3u8 muxed.mp4 % ffplay muxed.mp4 % ffplay -noframedrop muxed.mp4 % ffplay decrypted/muxed.mp4 % ffplay decrypted/muxed.ts % ffplay decrypted/cat.ts % ffplay -noframedrop decrypted/muxed.mp4 % ffplay -noframedrop decrypted/muxed.ts % ffplay -noframedrop decrypted/cat.ts
Yes, Ted, I'm getting dropped frames on playback. In VLC, it's in the Media Information - Statistics - Video - Lost counter. I'm not sure about stream 0... VLC says stream 0 is video. Also, another thing probably worth noting - if I regenerate timestamps with the help of, let's say MKVToolNix, by using its "fix bitstream timing info" option, the dropping frames issue is gone. What do you think about this? ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, February 13, 2020 6:09 AM, Ted Park <kumowoon1025@gmail.com> wrote:
I’m not able to reproduce the frame drops you mentioned, unless you mean the drops on playback?
Also, another thing probably worth noting - if I regenerate timestamps with the help of, let's say MKVToolNix, by using its "fix bitstream timing info" option, the dropping frames issue is gone. What do you think about this?
Ah, okay my mistake, I see what you mean now. Are the issues on frames 59, 119, 179, 239, 299? The fact that it happens every 60 frames seems to be indicative of something, though I’m not sure what yet. Was this originally a series of segments, perhaps 2.002 seconds long each that you re-segmented to be 4.004 seconds long?
Was this originally a series of segments, perhaps 2.002 seconds long each that you re-segmented to be 4.004 seconds long?
No, I didn't change the ts segments or m3u8 at all, they all were downloaded straight from the source.
Are the issues on frames 59, 119, 179, 239, 299?
Well, I'm not quite sure how to check this so precisely to be honest :-( ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, February 13, 2020 10:54 PM, Ted Park <kumowoon1025@gmail.com> wrote:
Also, another thing probably worth noting - if I regenerate timestamps with the help of, let's say MKVToolNix, by using its "fix bitstream timing info" option, the dropping frames issue is gone. What do you think about this?
Ah, okay my mistake, I see what you mean now. Are the issues on frames 59, 119, 179, 239, 299? The fact that it happens every 60 frames seems to be indicative of something, though I’m not sure what yet. Was this originally a series of segments, perhaps 2.002 seconds long each that you re-segmented to be 4.004 seconds long?
ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
No, I didn't change the ts segments or m3u8 at all, they all were downloaded straight from the source.
Are the issues on frames 59, 119, 179, 239, 299?
Well, I'm not quite sure how to check this so precisely to be honest :-(
I can only guess at this point, perhaps it resulted from the conversion from a 59.94 ntsc source to progressive. I was only able to figure out the issue you mentioned by forcing -vsync 0. If I don’t include that option (to preserve original timestamps) the issue disappears. I used this command: % ffmpeg -i test.ts -f image2 -vsync 0 -copyts -frame_pts true %d.png To inspect the frames and it doesn’t look like any were dropped or duplicated while muxing at least. There are also no frame drops when playing back the plain concatenated .ts file; the frame drops when playing back the file muxed using the hls muxer and playlist seem to be an A/V sync issue, adding -sync video when playing with ffplay seems to eliminate them (though I suspect it might cause audio drift with a longer file). I think this is due to the fact that not both the video and audio in each segment is 4.004 seconds long. At this point I would take all the information gathered/guessed and decide what the best option would be depending on what you are ultimately trying to do.
% ffmpeg -i test.ts -f image2 -vsync 0 -copyts -frame_pts true %d.png
When I use this command for my concatenated ts (I concatenate with "copy" on a Windows machine), there are no pictures created for frames # 60, 120, 180, 240 and 300...
not both the video and audio in each segment is 4.004 seconds long.
How to check the duration of audio stream? Is that the reason for the DTS warnings? I'm confused :-(
At this point I would take all the information gathered/guessed and decide what the best option would be depending on what you are ultimately trying to do.
Well, I just want to get a single file in a mainstream format like .mp4 or .mkv that plays with no dropping frames and of course with A/V streams synced. I'm still not sure what should be the steps in this case. Like I said before, right now if I remux this concatenated ts into mp4, the resulted file has 2 dropped frames at the beginning, is 1 second longer than ts and has 30.05 fps instead of 29.97 for some reason. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, February 14, 2020 5:36 PM, Ted Park <kumowoon1025@gmail.com> wrote:
No, I didn't change the ts segments or m3u8 at all, they all were downloaded straight from the source.
Are the issues on frames 59, 119, 179, 239, 299?
Well, I'm not quite sure how to check this so precisely to be honest :-(
I can only guess at this point, perhaps it resulted from the conversion from a 59.94 ntsc source to progressive. I was only able to figure out the issue you mentioned by forcing -vsync 0. If I don’t include that option (to preserve original timestamps) the issue disappears. I used this command: % ffmpeg -i test.ts -f image2 -vsync 0 -copyts -frame_pts true %d.png To inspect the frames and it doesn’t look like any were dropped or duplicated while muxing at least.
There are also no frame drops when playing back the plain concatenated .ts file; the frame drops when playing back the file muxed using the hls muxer and playlist seem to be an A/V sync issue, adding -sync video when playing with ffplay seems to eliminate them (though I suspect it might cause audio drift with a longer file). I think this is due to the fact that not both the video and audio in each segment is 4.004 seconds long.
At this point I would take all the information gathered/guessed and decide what the best option would be depending on what you are ultimately trying to do.
ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
Stream 0 in this case is the timed ID3 metadata “stream” and non monotonously increasing dts isn’t an error
On Mon, Feb 10, 2020 at 6:16 PM Crazy Red Elephant via ffmpeg-user < ffmpeg-user@ffmpeg.org> wrote:
This works, Moritz, thank you. However, for some reason it works only for the part0 file, two others don't open in Windows Media Player after decryption. That's weird...
What's also interesting is that there's about 17 KB difference in size between the part0 file decrypted with openssl (3,476 KB, which is 16 bytes less than the original encrypted one) and part0 decrypted from m3u8 (3,496 KB). Do you have any idea why it's like that?
Another thing is that I'm getting a "hex string is too short, padding with zero bytes to length" message but I suppose is fine since we use -iv 0...
The HLS standard says about encryption: "An encryption method of AES-128 signals that Media Segments are completely encrypted using the Advanced Encryption Standard (AES) [AES_128] with a 128-bit key, Cipher Block Chaining (CBC), and Public-Key Cryptography Standards #7 (PKCS7) padding [RFC5652]. CBC is restarted on each segment boundary, *using either the Initialization Vector (IV) attribute value or the Media Sequence Number as the IV*; see Section 5.2." In this case the IV for decryption of the first segment should be 0x0, the second 0x1 and so on and so forth.
On Mon, Feb 10, 2020 at 19:36:58 -0300, Micael Silva wrote:
The HLS standard says about encryption:
"An encryption method of AES-128 signals that Media Segments are completely encrypted using the Advanced Encryption Standard (AES) [AES_128] with a 128-bit key, Cipher Block Chaining (CBC), and Public-Key Cryptography Standards #7 (PKCS7) padding [RFC5652]. CBC is restarted on each segment boundary, *using either the Initialization Vector (IV) attribute value or the Media Sequence Number as the IV*; see Section 5.2."
In this case the IV for decryption of the first segment should be 0x0, the second 0x1 and so on and so forth.
Nice, I wasn't aware of that, and hadn't found the hlsdec code supporting this. On the other hand, I obviously successfully decrypted each segment with iv=0. *shrug* (again) Moritz
participants (5)
-
Crazy Red Elephant -
Micael Silva -
Moritz Barsnick -
Reino Wijnsma -
Ted Park