Is it just me or the devs forgot letter "c" somewhere in the code of the new
build of ffmpeg? When dealing with a .m3u8 file, I'm getting errors like
"Unable to open resource: cmy_actual_filename.ts" while there's no letter "c"
before my filenames in any of the filenames in my chunklist. One of
Yes, Carl, this looks very similar indeed... Good thing they have been
notified, it's a very weird issue.
‐‐‐ Original Message ‐‐‐
On Saturday, May 16, 2020 7:01 PM, Carl Eugen Hoyos wrote:
> Am Sa., 16. Mai 2020 um 17:30 Uhr schrieb Crazy Red Elephant via
> ffmpeg-user
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 de
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
wrote:
> On Mon, Feb 10, 2020 at 10:4
but I suppose is fine since we use -iv 0...
‐‐‐ Original Message ‐‐‐
On Monday, February 10, 2020 9:18 PM, Moritz Barsnick wrote:
> On Mon, Feb 10, 2020 at 13:40:59 +, Crazy Red Elephant via ffmpeg-user
> wrote:
>
> > I have a number of .ts files, .m3u8 playlist and a key to
Hi, Micael. I tried your command like this:
"ffmpeg -key 5e5852fab5eedf7c6b7a367b1fc140a1 -iv
-i crupto+file:part0.ts part0-decrypted.ts"
and got the following errors:
[NULL @ 02c5c712f980] missing picture in access unit with size 8
[h264 @ 02c5c7a50100]
‐‐‐ Original Message ‐‐‐
On Tuesday, February 11, 2020 12:26 AM, Moritz Barsnick
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
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 outp
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
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 f
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,
> 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
> % 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.00
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
wrote:
> > 4. A general question - is there any difference between (a) d
20746. This may result in incorrect
timestamps in the output file.
[mp4 @ 01a902a100c0] 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, 2
> 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
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
wrote:
> On 0
‐‐‐ Original Message ‐‐‐
On Thursday, April 2, 2020 10:14 PM, Mark Filipak
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
>
18 matches
Mail list logo