INTERACT FORUM
Windows => Television => Topic started by: RoderickGI on October 14, 2014, 06:04:20 pm
-
G'Day readers.
As per the title, would you like to be able to open JRiver TV recordings in JTV format directly in VideoReDo (http://www.videoredo.com/en/)?
I used to use VideoReDo extensively with recordings made in my old Topfield PVR to trim and remove ads. I would like to start managing the TV recordings in MC in the same way. The is no suitable conversion in JRiver to make this easy, so I have been looking into DirectShow solutions, since MC uses a DirectShow filter to open TV recordings in JTV format. DirectShow is a frustrating and time consuming thing to learn about, and finding the correct filters to multiplex and save demuxed JTV files is not easy.
So, I asked VideoReDo if they could open JTV files directly, and they are showing some interest. However, as it didn't work correctly at first try, they are wondering if there are other users who want this functionality, rather than just me. Fair enough, I thought. They shouldn't have to do all this work just for me. ;D
So, all you VideoReDo users who record TV using JRiver, get on over to this thread (http://www.videoredo.net/msgBoard/showthread.php?34798-Could-VideoReDo-open-JRiver-Media-Center-JTV-TV-recording-files) and show your support. That means posting in that thread if you would like them to make this work, not just reading the thread!
I am hoping that JRiver will be supportive of this request and new capability in VideoReDo if it is successfully implemented. JRiver, please let me know if this violates your policies, rules, copyright, or just pisses you off. :D
-
I used to use VideoReDo extensively with recordings made in my old Topfield PVR to trim and remove ads. I would like to start managing the TV recordings in MC in the same way. The is no suitable conversion in JRiver to make this easy, so I have been looking into DirectShow solutions, since MC uses a DirectShow filter to open TV recordings in JTV format. DirectShow is a frustrating and time consuming thing to learn about, and finding the correct filters to multiplex and save demuxed JTV files is not easy.
As I've said elsewhere before, I use .ts, VideoReDo and glynor's MCAutoQueue to process recordings and then go in manually and do the trimming and ad chopping. It's not clear to me how VRD treating .jtv natively will help this but I'm happy to support flexibility and improved capability until the mists drift away.
As I've commented over at the VRD thread, I'm interested to see comment from Yaobing and glynor on this one.
It makes sense to me that their support will help this initiative go ahead smoothly. The VRD dev, Dan203, is talking about reverse engineering:
I'm looking at the files you sent and the format is pretty basic. They're just ES files with some helper files conatining auxiliary info normally stored in the container. I saw a post on their forum where the developers basically said they did it this was to avoid paying licensing fees.
We might be able to tap into the DS filter in VRD, that's what we do with TiVo and what we use to do with WTV before I reverse engineered the format, but it might be easier to just figure out the jriver format and load them directly.
So, I'd expect that process would work a lot more smoothly with JRiver devs providing assistance. If they're not actively engaged, I'd be concerned about viability of the project.
Thanks for the push on this RodGI.. 8)
-
Thanks for the support Astromo.
This initiative is about supporting JTV TV recordings, which I prefer to use, as VRD already opens the TS recordings, as you know. JTV allows me to start watching a show, and part way through it decide to record the whole thing from the beginning. I use that quite a bit with programs that I stumble across or want to review what it is really about before recording. TS doesn't allow that.
Certainly I would like Yaobing and Glynor involved if at all possible. That is part of why I posted here. But I know Yaobing is pretty busy, so I'm not relying on it at this time. With Glynor's DirectShow expertise and new role championing TV functionality, it would be great if he made his thoughts known. (Hint, hint.) Once VRD can open JTV files, then his MCAutoQueue process should work for me as well.
So all you other readers, please get over to the VideoReDo forum and show support if you wish this to happen. It isn't a certainty yet by any means. The guys at VRD are being nice just considering the idea. If they know they might have lots of new customers, they will put more effort into it, or at least more enthusiasm, I'm sure.
-
I'd love to have the ability to auto remove the adverts from JTV recordings.
I used to use VideoRedo before migrating my TV watching/recording to MC and would like to be able to do so again one day.
Richard
-
I just added my support to their forum as well. I would have to upgrade to the newest version, but it would probably be worth it if this gets added.
-
My vote is in.
Ken
-
My vote is in.
Ken
Sweet, keep it coming.
Also everyone, RodGI's request was to wave the flag over at VRD. That way we've got a better chance of getting visibility. EDIT: This comment is effectively superseded - see post below with direction to a thread on Interact.
-
I also would like this. I use VideoReDo all the time.
-
Hello my name is Dan Haddix and I'm a developer for VideoReDo, a popular app for editing TV programs. We've recently got a few requests to add support for your jtv format. A customer sent me a short recording and I took a look at it in a hex editor. It seems to use ES for the audio and video and then some supplementary files which I assume contain stuff like the PTS values? I know the media center app includes a DirectShow filter that can decode these, but we're not a DirectShow app and we've had mixed results trying to use DirectShow as a source in the past. We tried for WTV and ended up writing our own demuxer instead because we get much better results when we can read the files directly. I considered attempting to reverse engineer the jtv format as well so we could write our own demuxer but I figured I'd ask here first and see if the developers of JRiver would be willing to help us out. If you guys could provide basic documentation on how your format works, or just email me your best technical explanation, it would greatly expedite our efforts to support our mutual customers.
If you have any other questions feel free to contact me privately or just post them here. I will monitor this thread for replies before I jump into attempting this on my own.
Thanks,
Dan
-
Just a word of positive support for this product. I personally use it for archiving shows recorded in WMC.
-
+1
-
Redirection:
Developer for VideoReDo, want to support JRiver format (http://yabb.jriver.com/interact/index.php?topic=92623.0)
Dan, the dev from VRD, started the above thread and is watching it for responses and input.
-
I know the devs here have a lot of irons in the fire, but hopefully they can find the time to provide the information you seek.
I look forward to jtv being available in VideoReDo, and it will probably be what causes me to finally upgrade my copy of VRD :)
-
Hi Dan,
Thank for your interest in our jtv format.
I am the developer who created the jtv format. We provide a DirectShow filter for this format. However, I understand you do not use DirectShow. So here it goes:
JTV file
JTV is a loose container. We use audio and video elementary streams from DirectShow filters (basically Microsoft MPEG-2 Demultiplexer). The jtv file itself is just a stub file that has some basic info, such as the file names of other supporting files that can be found in the same folder. The file paths saved in the jtv file are all relative to current folder. JTV also contains info about the beginning and end of recording, in the form of REFERENCE_TIME.
The JTV file consists of a header, as defined below,
class JRTVRecordingStubHeader
{
public:
char m_cID[4]; // file ID. must be "JTVS"
long m_lFileVersion;
REFERENCE_TIME m_aryrtStartTime[NumOfStreams];
REFERENCE_TIME m_aryrtStopTime[NumOfStreams];
};
and four relative file paths for the format file, the index file, the audio data file, and the video data file.
The recording usually contains one audio stream and one video stream. It may be audio only or video only (i.e. one of the streams maybe missing).
The actual audio and video streams are saved in two logical files - audio in .jta file, and video in .jts file. The "ts" in .jts stand for time-shifting, that is what this whole thing was intended for in the beginning (time-shifting live TV). The last letter is changed to 'a' for the audio data, 'f' for format data, 'i' for index. So .jtf file contains some formatting info, and .jti file contain an index table to quickly map a time-stamp to file location of of audio or video data file.
Audio and video data files
The actual audio and video data are split into multiple chunks. That is why I call jta and jts "logical" files. The .jts and .jta files should only contain the following:
char m_cID[4]; // Header ID. must be "JRSR"
long m_nVersion;
int64 m_FileSize; // the size of audio or video data (logical file size)
int64 m_ChunkSize; // the size of chunks
So to find data at a particular file location, you need to use the chunk size to figure out which chunk the data is actually in, and the offset into that chunk.
The audio and video elementary stream data contained in these files are logically divided into "samples". Actually we do not divide them, we just take the samples of a DirectShow filter's output and save them in the files, without interpretation. When we play the recording, we load the data sample-by-sample, and pass each sample to down-stream DirectShow filters. It is therefore up to you to interpret what each sample contains.
Audio and video sample headers
Each sample comes with a header. The following is the specification of the latest header:
struct MediaSampleHeader2
{
char cID[4]; // must be "MJTS"
LONG lPrevDataLen; // the size of previous sample, not including the header size
LONG lThisDataLen; // the size of the current sample, not including the header size
DWORD dwSampleIndex; // the serial number of the sample
REFERENCE_TIME rtStart; // the time-stamp (start time) of the current sample
REFERENCE_TIME rtEnd; // the time-stamp (end time) of the current sample
unsigned char bIsSyncPoint : 1; // the sample is a sync point
unsigned char bIsPreRoll : 1; // the sample is pre-roll
unsigned char bIsDiscontinuity : 1; // the sample represents discontinuity
unsigned char nChannelChange : 5; // channel change (the value changes by one, from 0 to 31 and back to 0, each time channel changes)
unsigned char nStreamType : 6; // MPEG1, MPEG2, AC3, AAC, etc. for audio, MPEG2, MPEG1, H264/AVC etc. for video
};
Older version (a few years ago) of jtv files use a different header. For now, I will just tell you the latest version.
A little more explanation of the last two items in the above structure:
nChannelChange - the value increments by one on channel change.
nStreamType - the stream type of audio or video.
When user switches channel, there is a possibility that the stream format is changed because of that. The nChannelChange flag allows you to pay attention to such fact, and examine the sample data to determine whether there is a format change or not. If we actually detected a format change during recording, then the nStreamType flag will contain the new format. The formats are defined as follows:
// MediaSampleHeader2 allocates a 6-bit field for StreamType
// so the max allowed value is 63
// We reserve the value 15 for TVAT_PinConnectionType/TVVT_PinConnectionType type which is used for special purposes
// the other 62 values (0 - 14 and 16 - 63) are for actual stream types, currently only 3 or 4 are used
enum TVAudioTypes
{
TVAT_MPEG1,
TVAT_AC3,
TVAT_MPEG2,
TVAT_AAC, // AAC_LATM used in European (British) HD TV channels
TVAT_RAW_AAC1, // used in Hauppauge HD PVR / Colossus
TVAT_EAC3,
TVAT_PinConnectionType = 15,
};
enum TVVideoTypes
{
TVVT_MPEG2,
TVVT_MPEG1,
TVVT_AVCH264,
TVVT_MPEG4,
TVVT_PinConnectionType = 15,
};
Note that in earlier versions only 5 bits were allocated for these media type values. That is why TVAT_PinConnectionType and TVVT_PinConnectionType have the value of 15 (the largest possible value at the time). Now the value 15 is stuck, even though the largest possible value is now 63.
The Format file (.jtf)
The format file contains some basic format info. Again, the actual structure has evolved over several versions. The beginning portion of the format file contains the CTSFormatFile structure defined below (the latest version).
enum StreamIndex
{
Audio = 0,
Video = 1,
NumOfStreams // 2
};
class AudioVideoTimeStamps
{
public:
REFERENCE_TIME rtAudioMaxTime; // max audio time stamp
REFERENCE_TIME rtVideoMaxTime; // max video time stamp
DWORD dwAudioSampleCount; // total number of audio samples
DWORD dwVideoSampleCount; // total number of video samples
INT64 llAudioLatestPosition;
INT64 llVideoLatestPosition;
};
#define TSFORMATFILE_VERSION 8
class CTSFormatFileV1
{
public:
int m_nVersion; // current version is 8
DWORD m_dwMaxTimeshift; // max time-shifting, in seconds
DWORD m_dwInsurance; // extra space allocated beyond the m_dwMaxTimeshift (it should be 2 - meaning 2% of m_dwMaxTimeshift)
int m_SplitterReaderMode; // should have a value of 2
BOOL m_bFilesStoppedGrowing; // should be true for TV recordings that have finished recording
AudioVideoTimeStamps m_TimeStamps; // defined above
};
class CTSFormatFile : public CTSFormatFileV1
{
public:
REFERENCE_TIME m_aryMinTimestamps[NumOfStreams]; // array of 2 elements, the first for audio, the second for video.
};
The next block of data in jtf file is CMediaTypeHeader defined below.
#define CUR_JRTV_FILE_VERSION 2
struct JRTVFileVersion
{
char cID[4]; // file ID. must be "JRTV"
long lFileVersion; // currently at 2, not changed since it was created
};
The JRTVFileVersion header is a bit redundant and not really significant. The significant version number is the version number in CTSFormatFileV1, currently at version 8.
class CMediaTypeHeader : public JRTVFileVersion
{
public:
long m_lAudioBufferSize; // buffer size of audio data
long m_lVideoBufferSize; // buffer size of video data
};
The two numbers represent the best estimate of how large the audio or video data buffer should be, for DirectShow filters. These numbers should be larger or equal to the sample (see "audio and video data files" above) data size.
Next, for format file version 8 (current version) and above, two 32-bit integers are in the file:
int nVideoStandard; // video standard, following DirectShow definition. NTSC, PAL etc. To get frame rate correct.
int nAvailableStreams; // how many streams are available (audio, and/or video)
They are defined below:
Video standard is as defined in DirectShow -
enum tagAnalogVideoStandard
{
AnalogVideo_None = 0,
AnalogVideo_NTSC_M = 0x1,
AnalogVideo_NTSC_M_J = 0x2,
AnalogVideo_NTSC_433 = 0x4,
AnalogVideo_PAL_B = 0x10,
AnalogVideo_PAL_D = 0x20,
AnalogVideo_PAL_G = 0x40,
AnalogVideo_PAL_H = 0x80,
AnalogVideo_PAL_I = 0x100,
AnalogVideo_PAL_M = 0x200,
AnalogVideo_PAL_N = 0x400,
AnalogVideo_PAL_60 = 0x800,
AnalogVideo_SECAM_B = 0x1000,
AnalogVideo_SECAM_D = 0x2000,
AnalogVideo_SECAM_G = 0x4000,
AnalogVideo_SECAM_H = 0x8000,
AnalogVideo_SECAM_K = 0x10000,
AnalogVideo_SECAM_K1 = 0x20000,
AnalogVideo_SECAM_L = 0x40000,
AnalogVideo_SECAM_L1 = 0x80000,
AnalogVideo_PAL_N_COMBO = 0x100000,
AnalogVideoMask_MCE_NTSC = ( ( ( ( ( ( AnalogVideo_NTSC_M | AnalogVideo_NTSC_M_J ) | AnalogVideo_NTSC_433 ) | AnalogVideo_PAL_M ) | AnalogVideo_PAL_N ) | AnalogVideo_PAL_60 ) | AnalogVideo_PAL_N_COMBO ) ,
AnalogVideoMask_MCE_PAL = ( ( ( ( AnalogVideo_PAL_B | AnalogVideo_PAL_D ) | AnalogVideo_PAL_G ) | AnalogVideo_PAL_H ) | AnalogVideo_PAL_I ) ,
AnalogVideoMask_MCE_SECAM = ( ( ( ( ( ( ( AnalogVideo_SECAM_B | AnalogVideo_SECAM_D ) | AnalogVideo_SECAM_G ) | AnalogVideo_SECAM_H ) | AnalogVideo_SECAM_K ) | AnalogVideo_SECAM_K1 ) | AnalogVideo_SECAM_L ) | AnalogVideo_SECAM_L1 )
} AnalogVideoStandard;
// when both audio and video streams are available in the recording, the nAvailableStreams value should be 3
enum AvailableStream
{
AudioAvailable = 1,
VideoAvailable = 2,
};
Next are audio and video media type data. This data is useful for setting up initial DirectShow filter connection. The audio and video media types may or may not stay the same during variable parts of the recording (see description of "Audio and video sample headers" above).
The data structure for media types follow DirectShow's definition of AM_MEDIA_TYPE. The data are written to file as follows:
AM_MEDIA_TYPE structure, excluding the last member of the structure (BYTE *pbFormat) - therefore the size written is sizeof (AM_MEDIA_TYPE) - sizeof(DWORD *).
The binary format data (cbFormat bytes).
-
Wow, Yaobing thanks so much on behalf of all of us.
Happy developing Dan.
-
You guys have been busy while I've been away. I'll go read that thread now. Thanks Astromo for giving everyone the heads up.
-
Thanks for coming over and asking the question Dan. Welcome to the JRiver forums. It seems like Yaobing is happy to share information, so I hope it is what you need.
Thank you Yaobing for sharing the information and making it easier for MC users to use VideoReDo as an editing tool. As Kensn said over on the VideoReDo forum, this could be a Win-Win for both parties, and all users.
Let's keep the dialogue going and get this done! :D
-
The index file (.jti)
Index file (.jti) provides a means of seeking during playback. Without it, one has to read audio and video data headers one by one in order to find correct location to play (given a time stamp).
The index file begins with a header:
#define TSINDEXFILE_VERSION 2
#define TSINDEXFILE_INVALID 0xFFFFFFFFFFFFFFFF
class CTSIndexFileHeader
{
public:
CTSIndexFileHeader()
{
m_nVersion = TSINDEXFILE_VERSION;
m_nIndexItems = 0;
m_rtFirstItems[0] = TSINDEXFILE_INVALID;
m_rtFirstItems[1] = TSINDEXFILE_INVALID;
}
int m_nVersion; // version, currently 2
INT64 m_nIndexItems; // number of items in the array of entries
REFERENCE_TIME m_rtFirstItems[2]; // the time stamps (audio, video) of the very first item.
// CTSIndexFileEntry * array of m_nIndexItems items that represent file offsets in the data stream
};
An array of index file entries follows the header. Each entry contains two 64 bit integer representing the file offsets in audio and video files at a particular time.
class CTSIndexFileEntry
{
public:
CTSIndexFileEntry() { SetInvalid(); }
inline void SetInvalid() { m_aryFileOffsets[0] = TSINDEXFILE_INVALID; m_aryFileOffsets[1] = TSINDEXFILE_INVALID; }
inline bool GetValid(int nAvailableStreams)
{
return (m_aryFileOffsets[0] != TSINDEXFILE_INVALID || (nAvailableStreams & AudioAvailable) == 0) &&
(m_aryFileOffsets[1] != TSINDEXFILE_INVALID || (nAvailableStreams & VideoAvailable) == 0);
}
inline INT64 GetOffset(StreamIndex StreamType) { return ((StreamType < 0) || (StreamType >= 2)) ? TSINDEXFILE_INVALID : m_aryFileOffsets[StreamType]; }
// offset into data file
INT64 m_aryFileOffsets[2];
};
To get a file location given a time stamp, use the following pseudocode:
int64 GetAudioPositionFromTime(REFERENCE_TIME rtTime)
{
REFERENCE_TIME rtMaxTimeShift = Format.m_dwMaxTimeshift * 1000000; // convert from seconds to REFERENCE_TIME unit (Format is read from the .jtf file)
REFERENCE_TIME llExtraMinutes = 3600000000; // equal to 6 minutes
// max range (in reference time unit) to hold in files, is equal to max time-shifting plus some extra for insurance
// the extra is 2% or 6 minutes, whichever is larger
REFERENCE_TIME rtMaxRangeInFiles = rtMaxTimeShift + max((rtMaxTimeShift * Format.m_dwInsurance / 100), llExtraMinutes);
int nIndexArraySize = Header.m_nIndexItems; // Header is the index file header
// seeking granularity is the separation in time between entries in the index file
REFERENCE_TIME rtSeekingGranularity = rtMaxTimeRangeInFiles / nIndexArraySize;
REFERENCE_TIME rtFirstItem = Header.m_rtFirstItems[Audio]; // similarly for Video
int IndexFileArrayIndex = (int) (((rtTime - rtFirstItem) / rtSeekingGranularity + 1) % nIndexArraySize);
CTSIndexFileEntry ifeRead;
INT64 nPosDesired = (INT64) (sizeof(CTSIndexFileHeader) + (IndexFileArrayIndex * sizeof(CTSIndexFileEntry)));
//
IndexFile.Read(nPosDesired, (BYTE *) pifeData, sizeof(CTSIndexFileEntry));
return ifeRead.GetOffset(Audio);
}
-
My last post completes the description of JTV format.
Feel free to ask if you have any questions.
-
Thank you. I will be looking at writing a demuxer for VRD soon, this will be very helpful.
-
Excellent. That looks like progress to me. Hopefully we will soon be able to read, edit and convert JRiver MC TV files in VideoReDo. :D
-
Dan, great to hear that you're taking a look at this.
Any update on where you're at?
EDIT:
Answering the question myself from info over at the VRD forum:
Could VideoReDo open JRiver Media Center JTV TV recording files? Post #24 (http://www.videoredo.net/msgBoard/showthread.php?34798-Could-VideoReDo-open-JRiver-Media-Center-JTV-TV-recording-files&p=116198#post116198)
-
G'Day folk,
The developers at VideoReDo are getting interested in the project to read JTV files directly into VideoReDo TV Suite V5 again. So I am reviving this old thread. As above, I want to do this so that I can trim padding from the beginning and end of TV shows recorded in JTV files, and also cut out commercials for those programs I want to keep.
I'm posting here because it is the Television forum. There also is a thread the Dan Haddix (Dan203) from VideoReDo started, which discusses the JTV format, over here: http://yabb.jriver.com/interact/index.php/topic,92623.0.html But that is in the MC20 for Windows forum, so I don't want to continue that one. Someone could combine the threads in this forum if they liked. :D
Hopefully this one will be seen and used. Waving at Yaobing.
Also, there is a thread over on the VideoReDo forum, currently on page 4: http://www.videoredo.net/msgBoard/showthread.php?34798-Could-VideoReDo-open-JRiver-Media-Center-JTV-TV-recording-files&p=123833#post123833
What is going on?
Yaobing, Dan, or more correctly DanR, has requested information about how to sync the audio and video start when opening a JTV file set. Could you provide an answer for him? Either here in this thread, or over on their forum, or directly if you have his contact details. Thank you.
Dan has also asked to for samples of TV recordings in H.264 format, in JTV files. I only have one sample of such a thing, and it is full length movie. Not much use for sharing via the internet, although I could if necessary. Our broadcasts are rarely in H.264 format here in Australia. I will still try to collect some smaller samples for him, but it may take a while. So, if anyone else can provide short H.264 format JTV file set samples, that would be great.
VideoReDo support have a specific methodology for unloading sample, or they get ignored and deleted. So if you could attach samples here, or upload them somewhere and provide a link, I will collect them all and provide them to Dan via their support people. Please make the sample short, perhaps five minutes tops, at least for now.
Thanks for any and all assistance.
Rod
-
If you are interested in this topic, perhaps check out the thread over here: http://yabb.jriver.com/interact/index.php/topic,92571.msg744310.html#msg744310
As of today there is some interest again in getting this done, and I don't want posts getting lost in this old MC20 forum.
Let us know if you are interested in VideoReDo having the capability to read JTV file sets.
Thanks.
-
I merged the MC20 topic into this topic.
-
Regarding audio video sync, each media sample (audio or video) carries with it a time-stamp in the fixed-size header (see "Audio and video sample headers" in one of my posts above). Sometimes a sample may have an invalid time-stamp carried in the header because the sample is not a key-frame.
If there is a synchronization issue, you can search for the next sample, sample-by-sample, to find one that has a better matching time-stamp. If a sample happens to have an invalid time-stamp, you can search for the next one, in particular, the next one with SyncPoint flag set.
To start with a certain time-stamp, you can use the index file (see pseudo-code int64 GetAudioPositionFromTime(REFERENCE_TIME rtTime) above) to get the file position of the audio data file. Similarly, you can get the file position of the video data file. Then you can open and read the audio and video data files. The file positions should be at the beginning of the header of a sample. The actual data follows the header. The header, see struct MediaSampleHeader2 above, has a member ( LONG lThisDataLen; ) that tells you how many bytes this sample contains. It allows you to read up the sample data, or skip it. After either reading or skipping the current sample, the file pointer should point at the header of the next sample.
-
TV stations in my area do not broadcast in H.264. So I had to record with Hauppauge HDPVR from a cable box. The output of HDPVR is H.264.
Here are a couple of samples:
A 15 second recording. (https://www.dropbox.com/s/dyi4wz3wk05968t/Program%20info%20not%20available%202016-09-19.rar?dl=0)
A 7 second recording. (https://www.dropbox.com/s/0ju8yxe9ww09s2x/Program%20info%20not%20available%202016-09-19%20%282%29.rar?dl=0)
-
Thanks for the information and samples Yaobing.
After saying that I didn't have any TV Channels broadcast in H.264, I realise that I have three of them. However MC doesn't recognise them as H.264 based on the values written to the [Compression] tag for recordings of those channels. They all contain AVC High@L4.0 1920x1080i@25fps video, with 2 or 6 Channels of AC-3 audio according to MediaInfo. The [Compression] tag for each is "jtv video (video: unknown codec, audio: ac3)".
I also have a movie recording from a different channel that has a [Compression] tag of "jtv video (video: h264, audio: unknown codec)", which MediaInfo reports as AVC Main@L3.1 720x576@25fps video, with 2 Channel AAC HE-AACv2 / HE-AAC / LC audio.
All the recordings play back in MC, but I guess there is some issue with evaluating a value for the [Compression] tag. The channel definitions all state these channels contain AVC1/H.264 Video, so MC does know what the video is.
Anyway, I have collated the samples and will send them to VideoReDo, and pass on your description of the sync process.
-
DanR asked an additional question, which I have already answered based on the code you previously provided. Please let me know if I am wrong!
His question:
Can you ask Yaobing if his REFERENCE_TIME units are 1,000,000 ticks / second?
My answer:
From the code segment that refers to REFERENCE_TIME, the comment on the second line defines the unit of measure.
int64 GetAudioPositionFromTime(REFERENCE_TIME rtTime)
{
REFERENCE_TIME rtMaxTimeShift = Format.m_dwMaxTimeshift * 1000000; // convert from seconds to REFERENCE_TIME unit (Format is read from the .jtf file)
REFERENCE_TIME llExtraMinutes = 3600000000; // equal to 6 minutes
3,600,000,000 "ticks" is equal to six minutes, so yes, the REFERENCE_TIME units are 1,000,000 ticks / second.
-
It is 10,000,000 ticks / second.
1 second = 10,000,000 REFERENCE_TIME unit.
1 REFERENCE_TIME unit = 10E-7 second = 100 x 10E-9 second = 100 nanoseconds.
-
Thanks Yaobing. I should have been more careful interpreting that comment. Silly brain divided by 3,600 instead of 360, seconds in six minutes.
-
Is there an easy way to convery JTV to MPG yet?
I'm just installing my old BlackGold TV card, the purpose is to record TV shows and edit them in Adobe Premiere.
Thx
-
You can convert JTV to MPG. Tools > Advanced Tools > Convert Format...
-
You can convert JTV to MPG. Tools > Advanced Tools > Convert Format...
Ah - thanks!
-
Yes, MC can convert JTV files to MP4... again you will get crappy stereo sound. Check the output results.
If you want to convert with the original audio intact, read these two posts/threads.
https://yabb.jriver.com/interact/index.php/topic,105793.msg736129.html#msg736129
https://yabb.jriver.com/interact/index.php/topic,107498.msg746546.html#msg746546