Difference between revisions of "Talk:MythDVBcut"
(Created page with "{{Quote|MythTV 0.26 filenames are based on UTC, while the Mythfrontend display uses local time. I'm still using mental arithmetic to convert, but users not in the UK may find ...") |
(Added "not working for me" section with my experience) |
||
| Line 1: | Line 1: | ||
| + | == File Name Parsing == | ||
| + | |||
{{Quote|MythTV 0.26 filenames are based on UTC, while the Mythfrontend display uses local time. I'm still using mental arithmetic to convert, but users not in the UK may find this more inconvenient.}} | {{Quote|MythTV 0.26 filenames are based on UTC, while the Mythfrontend display uses local time. I'm still using mental arithmetic to convert, but users not in the UK may find this more inconvenient.}} | ||
Filenames should not be processed for any information beyond the name of the file. While the name does contain the channel id and start time in some form, that information is nothing more than a convenient means to generate a unique filename. Whether the times are local or UTC should be irrelevant. If you need more information about the recording, you can have that passed to the script on the command line by the jobqueue. [[User:Wagnerrp|wagnerrp]] 14:21, 2 July 2013 (UTC) | Filenames should not be processed for any information beyond the name of the file. While the name does contain the channel id and start time in some form, that information is nothing more than a convenient means to generate a unique filename. Whether the times are local or UTC should be irrelevant. If you need more information about the recording, you can have that passed to the script on the command line by the jobqueue. [[User:Wagnerrp|wagnerrp]] 14:21, 2 July 2013 (UTC) | ||
| + | |||
| + | == Not Working For Me == | ||
| + | |||
| + | My cable switched a number of networks over from MPEG-2 to H.264. I had been using Myth's native lossless transcoding to cut commercials from MPEG-2 recordings, and occasionally exporting them to save in videos. This has worked wonderfully since the dawn of time or thereabouts. I'm recording with a HDPrime using a Cable Card. With Fios, I get almost all the channels without added restrictions. The recordings are .ts files containing H.264 video, so it looks like I should use the mythTScut_20180622.sh script. | ||
| + | |||
| + | When I ran it to test clipping a video, it had some problems. It appears to create a separate file for each segment in the working directory, which makes sense, but they are significantly off from the cutpoints I set in Myth. The second segment started 30 seconds or so early, and others were off, too. I didn't analyze it carefully to see if there was a consistent pattern. | ||
| + | |||
| + | The second problem is that it must have been re-encoding everything instead of just copying the segments, and in doing so the file size exploded. In my test program, the segment to the first 11 minutes was over 3GB, which was about the size of the entire original two-hour recording. Also the resulting files report as just 'data' when using the 'file' command instead of as a transport stream, not that that matters if it plays correctly. | ||
| + | |||
| + | I'm running mythtv-31.0 patched up to 2021-07-31. It's possible that changes to MythTV have broken something. | ||
| + | |||
| + | I found another program that promises to do frame-exact cropping of H.264 files with re-encoding of the few frames before or after the last I frame: avcut. I'm going to try modifying this script to use it instead of mythffmpeg. | ||
| + | |||
| + | Or maybe I'm just doing something wrong. [[User:Crow|crow]] 23:00, 15 Nov 2021 (UTC) | ||
Latest revision as of 23:02, 15 November 2021
File Name Parsing
MythTV 0.26 filenames are based on UTC, while the Mythfrontend display uses local time. I'm still using mental arithmetic to convert, but users not in the UK may find this more inconvenient.
Filenames should not be processed for any information beyond the name of the file. While the name does contain the channel id and start time in some form, that information is nothing more than a convenient means to generate a unique filename. Whether the times are local or UTC should be irrelevant. If you need more information about the recording, you can have that passed to the script on the command line by the jobqueue. wagnerrp 14:21, 2 July 2013 (UTC)
Not Working For Me
My cable switched a number of networks over from MPEG-2 to H.264. I had been using Myth's native lossless transcoding to cut commercials from MPEG-2 recordings, and occasionally exporting them to save in videos. This has worked wonderfully since the dawn of time or thereabouts. I'm recording with a HDPrime using a Cable Card. With Fios, I get almost all the channels without added restrictions. The recordings are .ts files containing H.264 video, so it looks like I should use the mythTScut_20180622.sh script.
When I ran it to test clipping a video, it had some problems. It appears to create a separate file for each segment in the working directory, which makes sense, but they are significantly off from the cutpoints I set in Myth. The second segment started 30 seconds or so early, and others were off, too. I didn't analyze it carefully to see if there was a consistent pattern.
The second problem is that it must have been re-encoding everything instead of just copying the segments, and in doing so the file size exploded. In my test program, the segment to the first 11 minutes was over 3GB, which was about the size of the entire original two-hour recording. Also the resulting files report as just 'data' when using the 'file' command instead of as a transport stream, not that that matters if it plays correctly.
I'm running mythtv-31.0 patched up to 2021-07-31. It's possible that changes to MythTV have broken something.
I found another program that promises to do frame-exact cropping of H.264 files with re-encoding of the few frames before or after the last I frame: avcut. I'm going to try modifying this script to use it instead of mythffmpeg.
Or maybe I'm just doing something wrong. crow 23:00, 15 Nov 2021 (UTC)
