"Non-monotonous DTS in output stream" error, previous and current values are equal
I have a number of .ts segments (AES-128 encrypted), .m3u8 chunklist for them and a key to decrypt them. My goal is to losslessly remux these .ts segments into one .mp4 file with no playback issues. I'm using the following command: "ffmpeg -allowed_extensions ALL -i chunklist.m3u8 -c copy output.mp4" but getting a bunch of "Non-monotonous DTS" errors. It results in the output file experiencing a dropped frame every 2-3 seconds during playback according to VLC player's media statistics window. I apologize in advance because the DTS issue was discussed here many times, however, the solutions described in other topics don't seem to be working for me and also, in my case the previous and current values in these errors are equal which is unusual. Here is the console output (all .ts parts are in the playlist, I've included only the output for the first three):
[hls,applehttp @ 0000022945ff9fc0] Opening 'key' for reading
[hls,applehttp @ 0000022945ff9fc0] Opening 'crypto:part0.ts' for reading
Input #0, hls,applehttp, from 'chunklist.m3u8': Duration: 02:34:55.36, start: 0.000000, bitrate: 0 kb/s Program 0 Metadata: variant_bitrate : 0 Stream #0:0: Data: timed_id3 (ID3 / 0x20334449) Metadata: variant_bitrate : 0 Stream #0:1: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709/unknown/unknown), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Metadata: variant_bitrate : 0 Stream #0:2: Audio: aac (LC) ([15][0][0][0] / 0x000F), 44100 Hz, stereo, fltp Metadata: variant_bitrate : 0
Output #0, mp4, to 'output.mp4':
Metadata: encoder : Lavf58.20.100 Stream #0:0: Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709/unknown/unknown), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 29.97 fps, 29.97 tbr, 90k tbn, 90k tbc
Metadata: variant_bitrate : 0 Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp Metadata: variant_bitrate : 0
Stream mapping: Stream #0:1 -> #0:0 (copy) Stream #0:2 -> #0:1 (copy) Press [q] to stop, [?] for help
[mp4 @ 00000229460c8500] Non-monotonous DTS in output stream 0:0; previous: 177177, current: 177177; changing to 177178. This may result in incorrect timestamps in the output file.
[hls,applehttp @ 0000022945ff9fc0] Opening 'crypto:part1.ts' for reading
[mp4 @ 00000229460c8500] Non-monotonous DTS in output stream 0:0; previous: 357357, current: 357357; changing to 357358. This may result in incorrect timestamps in the output file.
[mp4 @ 00000229460c8500] Non-monotonous DTS in output stream 0:0; previous: 537538, current: 537538; changing to 537539. This may result in incorrect timestamps in the output file.
[hls,applehttp @ 0000022945ff9fc0] Opening 'crypto:part2.ts' for reading
[mp4 @ 00000229460c8500] Non-monotonous DTS in output stream 0:0; previous: 717718, current: 717718; changing to 717719. This may result in incorrect timestamps in the output file.
[mp4 @ 00000229460c8500] Non-monotonous DTS in output stream 0:0; previous: 897898, current: 897898; changing to 897899. This may result in incorrect timestamps in the output file.
And here is the output I'm getting if I decrypt the .ts files separately (with openssl) and leave only first three of them in the chunklist:
[mpegts @ 00000209853e5040] Non-monotonous DTS in output stream 0:0; previous: 177177, current: 177177; changing to 177178. This may result in incorrect timestamps in the output file.
[NULL @ 00000209848ad900] missing picture in access unit with size 8 [mpegts @ 00000209853e5040] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
frame= 121 fps=0.0 q=-1.0 Lsize= 3492kB time=00:00:04.00 bitrate=7145.1kbits/s speed=99.1x video:3254kB audio:127kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 3.298792%
[mpegts @ 000001e6c395ba00] Non-monotonous DTS in output stream 0:0; previous: 176003, current: 176003; changing to 176004. This may result in incorrect timestamps in the output file.
[mpegts @ 000001e6c395ba00] Non-monotonous DTS in output stream 0:0; previous: 356183, current: 356183; changing to 356184. This may result in incorrect timestamps in the output file.
[mpegts @ 000001e6c395ba00] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
frame= 121 fps=0.0 q=-1.0 Lsize= 2872kB time=00:00:03.97 bitrate=5926.1kbits/s speed= 613x video:2647kB audio:126kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 3.568192%
[mpegts @ 000002881466a880] Non-monotonous DTS in output stream 0:0; previous: 176918, current: 176918; changing to 176919. This may result in incorrect timestamps in the output file.
[mpegts @ 000002881466a880] Non-monotonous DTS in output stream 0:0; previous: 357098, current: 357098; changing to 357099. This may result in incorrect timestamps in the output file.
[mpegts @ 000002881466a880] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
frame= 121 fps=0.0 q=-1.0 Lsize= 3204kB time=00:00:03.99 bitrate=6571.7kbits/s speed= 545x video:2971kB audio:127kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 3.428558%
It's basically the same but now the "missing picture in access unit with size 8" error appears as well for some reason. Maybe it has something to do with the rest of the .ts segments missing, not sure... I noticed the next thing - if I concatenate the .ts files and then remux the big .ts file into .mp4 there are no dropping frames, except in the beginning where I get 2 dropped frames for some reason. FFmpeg doesn't show any DTS errors in this case, however it shows some new ones - "start time for stream 0 is not set in estimate_timings_from_pts" and "pts has no value". The duration of the result .mp4 file is 1 second longer than the .ts one according to the file's properties which is weird. VLC player also detects the frame rate as 30.05 while it should be 29.97 so... I don't think it's a perfect solution. So I have the following questions: 1. Why these DTS errors appear? What exactly is wrong with my .ts files and how to check if my future .ts files have the same problem or not before remuxing with ffmpeg? 2. How to remux these .ts files properly so no "Non-monotonous DTS in output stream" or any other errors appear in ffmpeg and the result .mp4 plays with no issues and as close to the source as possible? 3. Why the "missing picture in access unit with size 8" error appears when I leave only first three .ts files in the chunklist? This error doesn't appear when all .ts files are there. 4. A general question - is there any difference between (a) decrypting all .ts parts separately, then concatenating them into one big .ts file and remuxing it into .mp4 and (b) concatenating all encrypted .ts parts first, then decrypting the big .ts result file and then remuxing it into .mp4? [Here](http://www.mediafire.com/file/twsn7mdew9aa8lx/test.zip/file) are the files I'm working with in a zip archive. I've included only the first three of the .ts segments there, that should be enough for a test. Any help will be greatly appreciated. Thanks! ~ Red Elephant
4. A general question - is there any difference between (a) decrypting all .ts parts separately, then concatenating them into one big .ts file and remuxing it into .mp4 and (b) concatenating all encrypted .ts parts first, then decrypting the big .ts result file and then remuxing it into .mp4?
This makes me think you are not decrypting the segments correctly, I had understood the specs to mean that if it isn’t specified, the IV needs to be incremented for each segment (so you would need to use 0x00000000000000000000000000000000 for the first segment, 0x00000000000000000000000000000001 for the second, etc. based on the initial media sequence number of 0). I don’t think the missing picture message at the end is unexpected, since the stream was cut arbitrarily after all, this is the result of my attempt at decrypting each segment with openssl and using cat to put them together (ffmpeg wasn’t used, except to test the file). https://media.kumowoon1025.com/videos/cat.ts <https://media.kumowoon1025.com/videos/cat.ts>
Guys please, I still have not found a solution and I'm so desperate :-( I asked this question on multiple sites and nobody is helping... ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, February 12, 2020 12:44 AM, Ted Park <kumowoon1025@gmail.com> wrote:
4. A general question - is there any difference between (a) decrypting all .ts parts separately, then concatenating them into one big .ts file and remuxing it into .mp4 and (b) concatenating all encrypted .ts parts first, then decrypting the big .ts result file and then remuxing it into .mp4?
This makes me think you are not decrypting the segments correctly, I had understood the specs to mean that if it isn’t specified, the IV needs to be incremented for each segment (so you would need to use 0x00000000000000000000000000000000 for the first segment, 0x00000000000000000000000000000001 for the second, etc. based on the initial media sequence number of 0).
I don’t think the missing picture message at the end is unexpected, since the stream was cut arbitrarily after all, this is the result of my attempt at decrypting each segment with openssl and using cat to put them together (ffmpeg wasn’t used, except to test the file). https://media.kumowoon1025.com/videos/cat.ts https://media.kumowoon1025.com/videos/cat.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 tried adding "-fflags +ignpts" before input but that didn't help, there are still DTS warnings, however, this time the values are not equal for some reason (except the first pair): [mp4 @ 000001a902a100c0] Non-monotonous DTS in output stream 0:0; previous: 6030, current: 6030; changing to 6031. This may result in incorrect timestamps in the output file. [mp4 @ 000001a902a100c0] Non-monotonous DTS in output stream 0:0; previous: 180204, current: 177177; changing to 180205. This may result in incorrect timestamps in the output file. [hls @ 000001a901cc9380] Opening 'crypto:part1.ts' for reading [mp4 @ 000001a902a100c0] Non-monotonous DTS in output stream 0:0; previous: 360384, current: 357357; changing to 360385. This may result in incorrect timestamps in the output file. [mp4 @ 000001a902a100c0] Non-monotonous DTS in output stream 0:0; previous: 540565, current: 537538; changing to 540566. This may result in incorrect timestamps in the output file. [hls @ 000001a901cc9380] Opening 'crypto:part2.ts' for reading [mp4 @ 000001a902a100c0] Non-monotonous DTS in output stream 0:0; previous: 720745, current: 717718; changing to 720746. This may result in incorrect timestamps in the output file. [mp4 @ 000001a902a100c0] Non-monotonous DTS in output stream 0:0; previous: 900925, current: 897898; changing to 900926. This may result in incorrect timestamps in the output file. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, February 23, 2020 3:15 PM, Crazy Red Elephant via ffmpeg-user <ffmpeg-user@ffmpeg.org> wrote:
Guys please, I still have not found a solution and I'm so desperate :-( I asked this question on multiple sites and nobody is helping...
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, February 12, 2020 12:44 AM, Ted Park kumowoon1025@gmail.com wrote:
4. A general question - is there any difference between (a) decrypting all .ts parts separately, then concatenating them into one big .ts file and remuxing it into .mp4 and (b) concatenating all encrypted .ts parts first, then decrypting the big .ts result file and then remuxing it into .mp4?
This makes me think you are not decrypting the segments correctly, I had understood the specs to mean that if it isn’t specified, the IV needs to be incremented for each segment (so you would need to use 0x00000000000000000000000000000000 for the first segment, 0x00000000000000000000000000000001 for the second, etc. based on the initial media sequence number of 0). I don’t think the missing picture message at the end is unexpected, since the stream was cut arbitrarily after all, this is the result of my attempt at decrypting each segment with openssl and using cat to put them together (ffmpeg wasn’t used, except to test the file). https://media.kumowoon1025.com/videos/cat.ts https://media.kumowoon1025.com/videos/cat.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".
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,
I tried adding "-fflags +ignpts" before input but that didn't help, there are still DTS warnings, however, this time the values are not equal for some reason (except the first pair)
I think igndts is more likely to affect the result but not sure in what way. Since you have bad timestamps in your original file, you’ll probably have to settle for workarounds. Like the first two frame drops seem unavoidable, they both have dts 0 and one has pts 0. The warnings do tell you how it handles the problem when it adjusts the timestamps so they’re not the same, with the caveat that it might not be accurate. You could also generate new timestamps based on frame rate but that might not be accurate, and cause audio sync issues. As I recall you said you downloaded the files directly, so the timestamp related frame drops probably happens to everyone who plays that stream? Are they actually disruptive, or could you just keep the original stream as is, knowing 1 out of 120 frames or something will be dropped when playing back? I’m pretty sure this is your best bet for keeping audio and video synchronized. Regards, Ted Park
Are they actually disruptive, or could you just keep the original stream as is, knowing 1 out of 120 frames or something will be dropped when playing back?
To me, yes. I know some other users also reported something about playback issues numerous times but the stream provider doesn't seem to care. I think I mentioned before that remuxing the video with MKVToolNix and the "generate timestamps" option checked kinda solves the problem but I'm not sure if the video and audio streams are synced after that... Also that produces an .mkv while I need .mp4 ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, February 25, 2020 8:49 PM, Ted Park <kumowoon1025@gmail.com> wrote:
Hi,
I tried adding "-fflags +ignpts" before input but that didn't help, there are still DTS warnings, however, this time the values are not equal for some reason (except the first pair)
I think igndts is more likely to affect the result but not sure in what way.
Since you have bad timestamps in your original file, you’ll probably have to settle for workarounds. Like the first two frame drops seem unavoidable, they both have dts 0 and one has pts 0.
The warnings do tell you how it handles the problem when it adjusts the timestamps so they’re not the same, with the caveat that it might not be accurate. You could also generate new timestamps based on frame rate but that might not be accurate, and cause audio sync issues.
As I recall you said you downloaded the files directly, so the timestamp related frame drops probably happens to everyone who plays that stream? Are they actually disruptive, or could you just keep the original stream as is, knowing 1 out of 120 frames or something will be dropped when playing back? I’m pretty sure this is your best bet for keeping audio and video synchronized.
Regards, Ted Park
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 03/15/2020 09:02 AM, Crazy Red Elephant via ffmpeg-user wrote:
Are they actually disruptive, or could you just keep the original stream as is, knowing 1 out of 120 frames or something will be dropped when playing back?
To me, yes. I know some other users also reported something about playback issues numerous times but the stream provider doesn't seem to care.
I think I mentioned before that remuxing the video with MKVToolNix and the "generate timestamps" option checked...
Can you help me find the "generate timestamps" option? I can't find it. I'd like to see what it does with a VOB that has 8 PGCs that are okay, but the 9th & 10th PGCs have audio in advance of video by about 4400ms. Regards, Mark.
Hi Mark, the option is called "Fix bitstream timing info", it's in the "Timestamps and default duration" box which is on the right side of the "Input" tab... ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, March 15, 2020 3:41 PM, Mark Filipak <markfilipak.windows+ffmpeg@gmail.com> wrote:
On 03/15/2020 09:02 AM, Crazy Red Elephant via ffmpeg-user wrote:
Are they actually disruptive, or could you just keep the original stream as is, knowing 1 out of 120 frames or something will be dropped when playing back?
To me, yes. I know some other users also reported something about playback issues numerous times but the stream provider doesn't seem to care. I think I mentioned before that remuxing the video with MKVToolNix and the "generate timestamps" option checked...
Can you help me find the "generate timestamps" option? I can't find it. I'd like to see what it does with a VOB that has 8 PGCs that are okay, but the 9th & 10th PGCs have audio in advance of video by about 4400ms.
Regards, Mark.
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".
Thanks, CRE. Now I know. On 04/01/2020 09:38 AM, Crazy Red Elephant via ffmpeg-user wrote:
Hi Mark, the option is called "Fix bitstream timing info", it's in the "Timestamps and default duration" box which is on the right side of the "Input" tab...
On Sunday, March 15, 2020 3:41 PM, Mark Filipak <markfilipak.windows+ffmpeg@gmail.com> wrote:
On 03/15/2020 09:02 AM, Crazy Red Elephant via ffmpeg-user wrote:
Are they actually disruptive, or could you just keep the original stream as is, knowing 1 out of 120 frames or something will be dropped when playing back?
To me, yes. I know some other users also reported something about playback issues numerous times but the stream provider doesn't seem to care. I think I mentioned before that remuxing the video with MKVToolNix and the "generate timestamps" option checked...
Can you help me find the "generate timestamps" option? I can't find it. I'd like to see what it does with a VOB that has 8 PGCs that are okay, but the 9th & 10th PGCs have audio in advance of video by about 4400ms.
So what do you think, Mark? I also noticed that if I use 1.2 version of ffmpeg there are no DTS errors and no dropping frames. The result file though acts weird when I try to create gifs from it for example. My gif creation software detects like 15 fps in it while "normal" videos give me the same amount fps in the gif as there are in the actual video. Not sure what's so special in version 1.2. Maybe it's because in old versions ffmpeg doesn't try to fix these timestamps or so... I still don't understand what's wrong with the source files :-( ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, April 2, 2020 10:14 PM, Mark Filipak <markfilipak.windows+ffmpeg@gmail.com> wrote:
Thanks, CRE. Now I know.
On 04/01/2020 09:38 AM, Crazy Red Elephant via ffmpeg-user wrote:
Hi Mark, the option is called "Fix bitstream timing info", it's in the "Timestamps and default duration" box which is on the right side of the "Input" tab... On Sunday, March 15, 2020 3:41 PM, Mark Filipak markfilipak.windows+ffmpeg@gmail.com wrote:
On 03/15/2020 09:02 AM, Crazy Red Elephant via ffmpeg-user wrote:
Are they actually disruptive, or could you just keep the original stream as is, knowing 1 out of 120 frames or something will be dropped when playing back?
To me, yes. I know some other users also reported something about playback issues numerous times but the stream provider doesn't seem to care. I think I mentioned before that remuxing the video with MKVToolNix and the "generate timestamps" option checked...
Can you help me find the "generate timestamps" option? I can't find it. I'd like to see what it does with a VOB that has 8 PGCs that are okay, but the 9th & 10th PGCs have audio in advance of video by about 4400ms.
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 04/06/2020 10:01 AM, Crazy Red Elephant via ffmpeg-user wrote:
So what do you think, Mark? I also noticed that if I use 1.2 version of ffmpeg there are no DTS errors and no dropping frames. The result file though acts weird when I try to create gifs from it for example. My gif creation software detects like 15 fps in it while "normal" videos give me the same amount fps in the gif as there are in the actual video. Not sure what's so special in version 1.2. Maybe it's because in old versions ffmpeg doesn't try to fix these timestamps or so... I still don't understand what's wrong with the source files :-(
ffmpeg -version ffmpeg version N-94664-g0821bc4eee Copyright (c) 2000-2019 the FFmpeg developers built with gcc 9.1.1 (GCC) 20190807 configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt
Sorry, CRE, I don't know anything about animated GIFs and I'm way to ignorant about ffmpeg. I can't help. I wish I could. At the rate of progress I'm making, maybe sometime after 2022. :-( - Mark. PS: I don't even know how to get the ffmpeg version. Look: libavutil 56. 33.100 / 56. 33.100 libavcodec 58. 55.101 / 58. 55.101 libavformat 58. 31.104 / 58. 31.104 libavdevice 58. 9.100 / 58. 9.100 libavfilter 7. 58.101 / 7. 58.101 libswscale 5. 6.100 / 5. 6.100 libswresample 3. 6.100 / 3. 6.100 libpostproc 55. 6.100 / 55. 6.100
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, April 2, 2020 10:14 PM, Mark Filipak <markfilipak.windows+ffmpeg@gmail.com> wrote:
Thanks, CRE. Now I know.
On 04/01/2020 09:38 AM, Crazy Red Elephant via ffmpeg-user wrote:
Hi Mark, the option is called "Fix bitstream timing info", it's in the "Timestamps and default duration" box which is on the right side of the "Input" tab... On Sunday, March 15, 2020 3:41 PM, Mark Filipak markfilipak.windows+ffmpeg@gmail.com wrote:
On 03/15/2020 09:02 AM, Crazy Red Elephant via ffmpeg-user wrote:
Are they actually disruptive, or could you just keep the original stream as is, knowing 1 out of 120 frames or something will be dropped when playing back?
To me, yes. I know some other users also reported something about playback issues numerous times but the stream provider doesn't seem to care. I think I mentioned before that remuxing the video with MKVToolNix and the "generate timestamps" option checked...
Can you help me find the "generate timestamps" option? I can't find it. I'd like to see what it does with a VOB that has 8 PGCs that are okay, but the 9th & 10th PGCs have audio in advance of video by about 4400ms.
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".
_______________________________________________ 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".
Try this: Add -dts_delta_threshold 0 *before* the input and retest. On Sun, 23 Feb 2020, 16:27 Crazy Red Elephant via ffmpeg-user, < ffmpeg-user@ffmpeg.org> wrote:
I tried adding "-fflags +ignpts" before input but that didn't help, there are still DTS warnings, however, this time the values are not equal for some reason (except the first pair):
[mp4 @ 000001a902a100c0] Non-monotonous DTS in output stream 0:0; previous: 6030, current: 6030; changing to 6031. This may result in incorrect timestamps in the output file. [mp4 @ 000001a902a100c0] Non-monotonous DTS in output stream 0:0; previous: 180204, current: 177177; changing to 180205. This may result in incorrect timestamps in the output file. [hls @ 000001a901cc9380] Opening 'crypto:part1.ts' for reading [mp4 @ 000001a902a100c0] Non-monotonous DTS in output stream 0:0; previous: 360384, current: 357357; changing to 360385. This may result in incorrect timestamps in the output file. [mp4 @ 000001a902a100c0] Non-monotonous DTS in output stream 0:0; previous: 540565, current: 537538; changing to 540566. This may result in incorrect timestamps in the output file. [hls @ 000001a901cc9380] Opening 'crypto:part2.ts' for reading [mp4 @ 000001a902a100c0] Non-monotonous DTS in output stream 0:0; previous: 720745, current: 717718; changing to 720746. This may result in incorrect timestamps in the output file. [mp4 @ 000001a902a100c0] Non-monotonous DTS in output stream 0:0; previous: 900925, current: 897898; changing to 900926. This may result in incorrect timestamps in the output file.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, February 23, 2020 3:15 PM, Crazy Red Elephant via ffmpeg-user < ffmpeg-user@ffmpeg.org> wrote:
Guys please, I still have not found a solution and I'm so desperate :-( I asked this question on multiple sites and nobody is helping...
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, February 12, 2020 12:44 AM, Ted Park kumowoon1025@gmail.com wrote:
4. A general question - is there any difference between (a) decrypting all .ts parts separately, then concatenating them into one big .ts file and remuxing it into .mp4 and (b) concatenating all encrypted .ts parts first, then decrypting the big .ts result file and then remuxing it into .mp4?
This makes me think you are not decrypting the segments correctly, I had understood the specs to mean that if it isn’t specified, the IV needs to be incremented for each segment (so you would need to use 0x00000000000000000000000000000000 for the first segment, 0x00000000000000000000000000000001 for the second, etc. based on the initial media sequence number of 0). I don’t think the missing picture message at the end is unexpected, since the stream was cut arbitrarily after all, this is the result of my attempt at decrypting each segment with openssl and using cat to put them together (ffmpeg wasn’t used, except to test the file). https://media.kumowoon1025.com/videos/cat.ts https://media.kumowoon1025.com/videos/cat.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".
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".
_______________________________________________ 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 2/23/2020 5:15 AM, Crazy Red Elephant via ffmpeg-user wrote:
Guys please, I still have not found a solution and I'm so desperate :-( I asked this question on multiple sites and nobody is helping...
Perhaps nobody has help to give? (As has been said many times, please do not top-post on this list; if you're unsure what that is, most search engines will tell.) z!
Am Di., 11. Feb. 2020 um 23:22 Uhr schrieb Crazy Red Elephant via ffmpeg-user <ffmpeg-user@ffmpeg.org>:
Here is the console output
Sadly not, if you need support here, please always provide the command line you tested together with the complete, uncut console output, don't forget to test current FFmpeg git head, nothing else is supported here. And please find out what top-posting means and avoid it here, it is considered rude by many people here to ignore this advice. Carl Eugen
participants (6)
-
Carl Eugen Hoyos -
Carl Zwanzig -
Crazy Red Elephant -
Dennis Mungai -
Mark Filipak -
Ted Park