I have already did my subtitle file in notepad and saved it as a SRT file but I couldn't load it in my mp4 file through VLC?
1
00:09:37.570 --> 00:10:80.570
(car speeding across the road)
2
00:11:70.570 --> 00:13:47.570
(screeching of tires)
3
00:13:70.570 --> 00:15:63.570
(car crash)
4
00:15:70.570 --> 00:20:87.570
(sirens)
5
00:24:77.570 --> 00:25:97.570
(phone buzzes)
6
00:34:43.570 --> 00:39:40.570
Hello?
Yes, it's me.
7
00:41:50.570 --> 00:42:73.570
I'm sorry?
8
00:49:90.570 --> 00:51:30.570
Okay, I'm coming.
9
00:54:53.570 --> 01:02:10.570
(scribbles of pen)
10
01:05:00.570 --> 01:06:67.570
[car slows down]
11
01:08:00.570 --> 01:10:57.570
(opening and closing of car door)
12
01:11:43.570 --> 01:16:37.570
Can you take me to St. Patrick's Hospital please?
Thank you.
13
01:21:90.570 --> 01:23:20.570
Um, excuse me?
14
01:25:00.570 --> 01:30:80.570
Uh, I'm Penelope and I'm here to see Chris Wardsworth.
He was brought in an hour ago.
15
01:30:97.570 --> 01:33:63.570
Relationship with patient?
16
01:33:67.570 --> 01:35:97.570
He is my brother.
17
01:38:90.570 --> 01:42:80.570
Go to the elevator and ride up to the fourth floor.
18
01:43:50.570 --> 01:44:77.570
Thank you.
19
01:46:97.570 --> 01:55:90.570
(footsteps along the corridor)
20
02:03:00.570 --> 02:04:77.570
Miss Wardsworth.
21
02:05:90.570 --> 02:08:47.570
Yes?
Come here.
22
02:10:90.570 --> 02:18:00.570
Can you see your marks?
You barely pass your exams!!!
Your brother would have passed it with flying colors.
23
02:19:37.570 --> 02:21:97.570
I'm sorry, I'll work harder next time.
24
02:26:15.570 --> 02:28:90.570
Every bad student said that. She is hopeless.
25
02:39:00.570 --> 02:42:18.570
Hey Carrie!
God, Chris, it's good to see you!
26
02:42:53.570 --> 02:49:07.570
Uh, where’s your troublesome sister?
Oh, who knows. Probably in her room sulking about her marks.
27
02:50:80.570 --> 02:54:07.570
She just won't work hard, isn't it?
She's so lazy.
28
02:54:20.570 --> 02:58:30.570
Oh, I’m sorry you have such a dumb sister.
We can’t change that, can we?
29
03:00:70.570 --> 03:02:90.570
Do you really hate me that much?
30
03:04:00.570 --> 03:07:50.570
I’ll take that as a yes… but why?
31
03:10:30.570 --> 03:17:77.570
Is it because you’re jealous?
You are a perfectionist that hates to lose?
That you’d like to be the better one?
32
03:20:43.570 --> 03:27:60.570
Look I might have teased you when we were younger and…
I really want to apologize for being a jerk.
33
03:28:90.570 --> 03:30:37.570
It's okay.
34
03:30:43.570 --> 03:39:70.570
I know you’re still mad at me. But, from now on we’ll be living together and…
No matter what happens we’ll get through this together, okay?
35
03:41:50.570 --> 03:45:87.570
I promise I’ll always be by your side.
Thank you.
36
04:30:93.570 --> 04:32:13.570
“I love you more than Spongebob loves Patrick”
37
04:37:13.570 --> 04:38:67.570
How do I solve this?
38
04:40:00.570 --> 04:44:30.570
Hey sis, how’re you doing?
Oh my gosh Chris, you came in the right time!
39
04:40:57.570 --> 04:48:30.570
I’m not doing good but, uh…
Do you know how to find "x"?
40
04:48:70.570 --> 04:51:00.570
Oh, geometry. Let me see.
41
04:59:80.570 --> 05:01:67.570
Yeah, there you go.
42
05:02:05.570 --> 05:03:23.570
Oh my gosh, but how???
43
05:03:70.570 --> 05:07:07.570
Uh… maybe it would be easier if you weren’t that stupid?
44
05:07:63.570 --> 05:12:07.570
[inner voice] Nobody likes you, you know?
Ah… Penelope sorry I don’t mean… I don’t mean--
45
05:13:10.570 --> 05:16:23.570
GET OUT! GET OUT I DON’T WANT TO SEE YOU ANYMORE!!!
Penelope!!!
46
05:16:83.570 --> 05:17:93
GO AWAY!!!
47
05:18:27.570 --> 05:22:13.570
Penelope! I’m sorry, uh… Can I…UGH
48
05:38:00.570 --> 05:38:60.570
Goodbye
49
06:37:20.570 --> 06:40:03.570
Chris? Where is he?
50
06:40:83.570 --> 06:45:50.570
He is currently in surgery. The surgeons are trying their best to save him.
51
06:46:00.570 --> 06:51:63.570
He has broken some of his bones, ribs, and he has lost a lot of blood.
52
06:52:28.570 --> 06:54:17.570
But… he’ll be okay, right?
53
06:55:03.570 --> 06:59:27.570
Well, I can’t be certain about that. I apologize.
54
06:59:80.570 --> 07:07:57.570
However, I think you should better be prepared for the worst.
He wasn’t in a good shape when he was brought in.
55
07:10:83.570 --> 07:14:10.570
I’m sorry. We have tried our very best.
56
07:15:60.570 --> 07:18:53.570
But… he lost too much blood.
57
07:23:13.570 --> 07:25:83.570
…May I have a last look of him?
58
07:32:03.570 --> 07:33:93.570
Hey. Chris...
59
07:34:60.570 --> 07:36:93.570
Hey don’t you do this to me!
60
07:38:53.570 --> 07:40:70.570
Why are you dead...
61
07:42:73.570 --> 07:49:80.570
You are my brother…
My only friend and my… and my soulmate in the world…
62
07:50:27.570 --> 07:51:90.570
Why are you dead?
63
07:56:13.570 --> 07:58:33.570
Miss, I’m sorry, you have to leave now.
64
07:59:03.570 --> 08:01:33.570
My team will continue the work.
65
08:02:87.570 --> 08:05:53.570
No, I haven’t said my goodbyes yet…
66
08:10:83.570 --> 08:11:97.570
No...
67
08:12:30.570 --> 08:13:47.570
Please, miss.
68
08:15:47.570 --> 08:16:43.570
Let's go.
69
08:23:25.570 --> 08:24:13.570
NO!!!
70
08:27:93.570 --> 08:30:93.570
Miss. are you alright? We have the accused with us now.
71
08:31:23.570 --> 08:35:33.570
He admitted knocking down Mr. … Mr. Wardsworth.
72
08:36:72.570 --> 08:37:10.570
I'm fine.
73
08:37:90.570 --> 08:39:67.570
Miss Wardsworth, this is Mr. Cheng.
74
08:39:69.570 --> 08:42:10.570
Miss Wardsworth, I swear! I didn’t mean to knock him down!
75
08:42:47.570 --> 08:45:90.570
I- I have had some alcohol and I thought I was okay so I drove anyway.
76
08:46:27.570 --> 08:52:67.570
But- but then- he- when I blinked, and my eyesight was blurry and… he was standing there!
77
08:52:70.570 --> 08:56:37.570
And I tried to swerve away from him! But- but it was too late!!
78
08:56:57.570 --> 08:58:90.570
I tried! I really tried!! I’m sorry!!!
79
08:59:50.570 --> 09:00:27.570
I hate you!!!
80
09:26:97.570 --> 09:27:60.570
Dear Chris,
81
09:28:00.570 --> 09:33:87.570
I don’t know if you will be able to read this one day
But I just want to tell you, I’m sorry.
82
09:34:40.570 --> 09:38:03.570
I miss you so much and I can’t stop thinking about us when we were younger.
83
09:38:70.570 --> 09:43:13.570
I was wondering after all these years, do you still feel ashamed of me?
84
09:43:87.570 --> 09:51:67.570
I am so sorry for blocking you out, but I am always late for everything,
And I only just realized how important you are to me.
85
09:52:37.570 --> 09:56:50.570
You are my soulmate, my teacher, my only friend in life.
86
09:56:90.570 --> 10:01:93.570
Without you, I will never be okay.
I was told to move on, but I can’t.
87
10:02:53.570 --> 10:12:00.570
The guilt of my stupidity and ignorance is eating me alive.
The overwhelming pain assaulted every ounce of my body, especially my heart.
88
10:12:90.570 --> 10:15:40.570
I will never stop regretting for blocking you out.
89
10:16:00.570 --> 10:19:47.570
I miss you. Miss, not missed. Present tense.
90
10:18:83.570 --> 10:21:60.570
Regards, Your sister.
I'm stupid, pls help.bgdfstewasrdtfyguhip[awesrdtfy[]\QEAWRS[WEASRFUOIPO[AERSTRDYFUGIUHOIK
As long as the file that you are playing is a video and returns the number of frames per second, vlc will look for a file with exactly the same name as the video but ending with .srt (i.e. myvideo.avi --> myvideo.srt)
The srt file must be in the same directory as the video file.
You can manually load a subtitle file with Subtitle-->Load subtitle file
Related
Here is what I suppose: When the code causes a trap (system call or exceptions), xv6 will replace the registers with certain values to transfer the control to alltraps(), in which trap() is called.
But sometimes xv6 runs into trap() out of my expectation, and I want to know why it got into this trap. When debugging, after I set a break point in trap() and xv6 stopped here, I can only see this in the debugger (I'm using CLion). In the call stack, the bottom stack frame is alltraps() so I can't find out when and why the trap is caused.
I want to find out in which file, at which line the trap is caused for a certain call of trap(). Is this possible?
If you will examine trap() code more carefully, you will see that it also handles hardware interrupts (timer, ide and so on).
36 void
37 trap(struct trapframe *tf)
38 {
39 if(tf->trapno == T_SYSCALL){
...
47 }
48
49 switch(tf->trapno){
50 case T_IRQ0 + IRQ_TIMER:
51 if(cpuid() == 0){
52 acquire(&tickslock);
53 ticks++;
54 wakeup(&ticks);
55 release(&tickslock);
56 }
57 lapiceoi();
58 break;
59 case T_IRQ0 + IRQ_IDE:
...
So what are you seeing is hardware interrupt coming and processor transfers control to one of the IDT vectors then to alltraps then to trap(). Most likely you are facing timer interrupt, which is used for context switch.
I want to find out in which file, at which line the trap is caused for a certain call of trap(). Is this possible?
No it is not possible, because this is a hardware event and it has no relation to source code.
i have the following stack trace:
0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26
1 MyApp 0x000836bd TFSignalHandler + 28
2 libsystem_c.dylib 0x33eac727 _sigtramp + 34
3 ??? 0x00000002 0x0 + 2
4 MyApp 0x000803f1 msgpack_unpack_next + 112
5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74
6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26
7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146
...
And i'm wondering how to read it:
I assume i go from the bottom up, eg line 7 called line 6 called line 5, etc.
What does the '+ 112' on line 4 mean? Is that a line number in the code file where it crashed?
What does the '???' on line 3 mean?
Thanks a lot
0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26
Crash was generated from +[TFCrashHandler backtrace] + 26; from whatever instruction fell at that symbol location + 26 bytes.
If that is really the bottom of your stack trace and it crashed there, then the TCrashHandler is obscuring the real crash. The real crash looks to be a couple of frames above.
1 MyApp 0x000836bd TFSignalHandler + 28
TFSignalHandler was what called +backtrace.
2 libsystem_c.dylib 0x33eac727 _sigtramp + 34
Ewww... a signal trampoline. The app received a signal and the a trampoline was set to call TFSignalHandler().
There are situations where a signal handler might be called on a random thread. I.e. there is a minuscule chance that this particular crash had nothing to do with the parser and everything to do with a crash somewhere else. However, without knowing more about the parser, I'd question whether it is hardened against malicious input (which could certainly cause a crash like this).
3 ??? 0x00000002 0x0 + 2
Stack was undecodable. Ignore. Meaningless. Best case; fallout from compiler optimization. Worst case; somebody pooped on the stack and the backtrace mechanism can't figure out what is going on (highly unlikely -- usually, stack poop splatters to the point of preventing a full backtrace).
4 MyApp 0x000803f1 msgpack_unpack_next + 112
Ooooh... trickzy. Someone is using C to parse stuff. And it crashed. Whatever instruction was 112 bytes from the entry point to the function went boom. But, not really, because it called the signal handler and was handled by that; which is still a boom but the signal handler has effectively destroyed additional forensic evidence.
The "trickzy" comment references that an optimizing compiler against a big pile o' C can end up collapsing frames to the point that the crash could have happened in a function well below this one.
5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74
MessagePackParser was parsing when things went horribly wrong.
6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26
7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146
Ahh... yes.... somebody done grabbed some data from HTTP and it was malformed, causing the crash.
Bottom line; the parser got bogus input and crashed. There was a signal handler in place that tried to help by creating a backtrace, but -- apparently -- didn't really reveal any more info. A long shot alternative is that the signal was generated somewhere else and this thread was randomly selected to handle it -- if you can consistently recreate this crash, the random-thread-signal case is unlikely.
Unless you have a capture of the input data or can somehow guess how msgpack_unpack_next() might crash, you are out of luck without providing more info.
The '???' is something that can't be identified, probably code that was compiled without symbols, but could also be something else.
Those are the line numbers in the implementation file. And the hex is the pointer in memory to the line call.
Heres the problem. I have an app that is essentially an image gallery, it pulls images down from an xml feed, and archives them locally, then gradually loads 5 images at a time into the scroll view to be displayed.
I have had thousands of problems with using [UIImage imageNamed:...] and NSURLRequest/NSData as both cause the app to cache excessive amounts of data. Anyway, I now have the app running at an almost constant 25-30MB, with no sudden spikes, and with only a few kB of data being leaked from memory (due to NSKeyedArchiver and me retaining some values). However the app ALWAYS gets terminated by the OS for (what seems like) no apparent reason.
Sorry if I'm being a bit stupid and not spotting something, the crash report does appear to be telling me that tonnes of memory has been paged by the app, however the allocations and leaks instrument is telling a different story... and really I supposed my question is more along the lines of "why is instruments lying to me?"
Incident Identifier: D258E503-D024-4265-B079-E6C47DE5DA29
CrashReporter Key: c3904eb2c9cf4bf4f89f53fb9c836ad44586684f
OS Version: iPhone OS 3.2.1 (7B405)
Date: 2010-09-21 13:27:50 +0100
Free pages: 464
Wired pages: 12587
Purgeable pages: 0
Largest process: MediaLib
Processes
Name UUID Count resident pages
MediaLib <6db92ce87a5d7e287702f2cb87ba8c53> 30579 (jettisoned) (active)
debugserver <f885fe2348e72988381a73137cc90c7b> 127
notification_pro <4c9a7ee0a5bbe160465991228f2d2f2e> 64
notification_pro <4c9a7ee0a5bbe160465991228f2d2f2e> 64
afcd <ddda2413b8953e5c56721dfe05a82d78> 68
syslog_relay <1c73f841b191556b6911bc6b4736b50f> 63
DTMobileIS <b34df288cd9a07a995933bbd6b66717a> 1169
notification_pro <4c9a7ee0a5bbe160465991228f2d2f2e> 64
ptpd <e3f855cfd629600a4812e7e90c77667e> 191
syslogd <6990426209e51a8ee13c91cd1a050a2e> 78
mediaserverd <2eda3ce5e1c8a1a4d7b8271cef1f2d12> 314
debugserver <f885fe2348e72988381a73137cc90c7b> 74
debugserver <f885fe2348e72988381a73137cc90c7b> 74
debugserver <f885fe2348e72988381a73137cc90c7b> 74
lsd <eb108595d2a932a8d244d1ab7386cd0f> 121
apsd <0775f0d80d1cd1fb4b562d2f94caf051> 172
notifyd <74e4a487a89c31f68917b22605baf6c6> 68
BTServer <21dd98c0ab29b910cd51cb703a9cb9b9> 107
CommCenter <e4b9cc04f083f22232c92ee1363fe669> 170
SpringBoard <745085d9a24a8529f0ceb6c33d766873> 4821 (active)
accessoryd <59ca0ba146c28bf5c8ab6e3d2e81bbad> 97
configd <36001fe17103f8af6d3b525cb23ac8a0> 305
fairplayd.K48 <2d997ffca1a568f9c5400ac32d8f0782> 85
locationd <60fd4d90fec18a76ffc0b8a45351fe54> 600
mDNSResponder <a6f01dd493e3d2bfe318f5d44f8508e2> 107
lockdownd <378f09833cdc57b1b60e42d79c355938> 273
MobileStorageMou <7f2cd9f90fab302a42a63460b1c4d775> 67
launchd <880e75c2db9c0f670516c58935e89b58> 80
**End**
Many thanks in advance for someone who can give me a slap and point me in the right direction ;)
EDIT:
I have just run the app through the activity monitor instrument and this is giving me a "Real Memory" readout of 65-80MB, could this be due to allocation of memory on another thread, which isn't picked up by the allocations instrument?
You should know that NSImage#imageNamed: caches the image. In other words, you lose fine control over the life cycle of those images. Use NSImage#initWith... instead and the cache will not be used.
Also know that a .png image that is a 2KB download can easily be a 6MB image when loaded into an UIImage. Image data is decompressed when loaded into an UIImage so don't look too much to the original size. Look at the size of the bitmap. Usually simply width * height * 4.
You mention that NSURLConnection and NSData are causing memory issues. This is probably because of improper usage. Like failing to do proper memory management.
Post code or more details if you want better hints about resource management.
I read a few memory-leaking issues with UIImagePickerController, so I changed my code to using member variable and was able to take more than a few pictures with the camera. However, I find the photo-taking to take longer and longer time, and eventually it crashed at around 25 photos.
There are two things I do after the photo in the didFinishPickingMediaWithInfo,
1) scale the image down and display that (50x50)
2) save a 320x460 to CoreData
I didn't release any UIImage since it's on the autorelease pool.
What should I do to let the picture-taking go on forever?
Below is the crash log (Type of crash log is listed as Low Memory)
CrashReporter Key: 8e197e26271ae3c2c4d3e725807d023e3c2354cb
OS Version: iPhone OS 3.0 (7A341)
Free pages: 251
Wired pages: 10127
Purgeable pages: 0
Largest process: Journal
Processes
Name UUID Count resident pages
Journal 8960 (jettisoned) (active)
debugserver 130
MobilePhone 529 (jettisoned)
syslog_relay 53
notification_pro 54
DTMobileIS 2285
notification_pro 53
ptpd 276
mediaserverd 252
debugserver 77
debugserver 78
SpringBoard 2470 (active)
notifyd 80
BTServer 123
CommCenter 262
accessoryd 84
configd 70
configd 266
fairplayd 67
mDNSResponder 89
lockdownd 252
syslogd 82
launchd 70
Can you provide backtrace / more crash information?
Is it possible to manage the UIImages yourself, or wrap the call that gives you an autoreleased UIImage with your own NSAutoreleasePool so you can control its lifetime?
Have you tried using Instruments to detect for any possible memory leaks?
This question is pretty old, so hopefully already solved but consider 2 points:
CoreData is a terrible place to save BLOBS, it's really good at text but not so much for binary data.
Your image will live in memory until you give it some place else to go, the only way to get them out of memory is releasing all references to that data.
I would consider caching your images to the file system until they are required again. Basically follow this process:
Capture Image1
Want to take another? Capture Image2 and write Image1 out to disk.
Store the filename for Image1 in CoreData for later retreival.
Repeat as necessary.
It is still possible that you will run out of disk space eventually, but you will have a lot more available disk space than memory, and you can always purge unwanted images from disk or force your user to deal with them in some other convenient manner (upload to the cloud for example).
I have the following data: F0 60 5B 50 BB 27 C4 01
I am 99% certain that this represents the date: 21/04/2004 17:11:33
I cannot for the life of me work out how it is encoding it. Am I being dense? I've tried just reading it in as a binary date, but that comes back with a date way in the future. I've tried assuming it's number of ticks since some epoch, but to no avail.
Does anyone have any suggestions?
Edit: The data is from an export of an application over which I have no control. I am trying to extract data from this dump in order to make reporting of the contents of the application a little easier.
Another sample is: 90 53 EC 85 CB B2 C5 01 -> 06/09/2005 11:12:44
I'm only about 50 sure that this date is correct (which is why I didn't include it previously).
I think I'm onto something. If you reverse bytes (so that they read 01 C4 27 BB ... and feed that into DateTime.FromBinary, you'll get 21.04.0404 16:11:33, which is very close digit-wise to your date.