d2v file creation on linux

[Guest]

Soon.

[d'Oursse]

about MuxFile, there are some strange tests on it (MuxFile > 0 and MuxFile != (struct _iobuf *) 0xffffffff ). What do you want to do with these tests ? I think that the first one should be != NULL. But the second one ?

Also, in getbit.c, there are sometimes pcm[0] and pcm[This_Track] in Next_Packet (in getbit.c, in Next_Packet). Is it normal ?

[Guest]

MuxFile == 0xffffffff means demuxing is disabled.

MuxFile == 0 is set to enable demuxing but the file handle hasn't yet been opened.

MuxFile > 0 && != 0xffffffff is the valid opened file handle when demuxing.

Yes, as noted in the changes listing for 1.4.4 rc1, Decode AC3 to WAV was broken for tracks 2-8. It has been fixed. All the pcm[0]'s should have been pcm[This_Track].

Version 1.4.4 will be released very soon, at which point you can get the new source code.

[d'Oursse]

ok, thank you. Nevertheless, would it be possible to cast with (FILE *) and not (struct _iobuf *) ? there's a compiler warning with struct _iobuf

right now, i have something that compiles and links fine. I'm trying to write a CLI with that library

[Guest]

Nevertheless, would it be possible to cast with (FILE *) and not (struct _iobuf *)? Sure. I can't remember why I did it that way.

[d'Oursse]

stupid question : there's no main function in the dgindex code ?

a related question : where can I get the general structure of the creation of the d2v file ? (the functions to call, in which order, etc...) I see that there are some in mpeg2dec.c, in the creation of the main window. Is there something elssewhere ?

[Guest]

stupid question : there's no main function in the dgindex code ? All Windows programs begin at WinMain(). Leaving the CLI aside, it just sets up the main window and gets the message loop going. After that, everything is triggered by GUI controls sending messages to the message loop, WndProc().

a related question : where can I get the general structure of the creation of the d2v file ? (the functions to call, in which order, etc...) I see that there are some in mpeg2dec.c, in the creation of the main window. Is there something elsewhere ? I'll give a rough overview:

The user selects menu option Save Project.

WndProc() receives a message at case IDM_SAVE_D2V. The D2V file is opened. The D2V_Flag is set to true. process.locate is set to LOCATE_RIP. A thread is started to run MPEG2Dec. The processing for this GUI message is completed.

The MPEG2Dec thread starts. It first sets up the process structure. Check_Flag is already set from the initial loading of the file, so that big chunk of code conditional on !Check_Flag is skipped. The header and settings sections of the D2V file are now written. The MPEG decoding loop now is entered. Get_Hdr() and Decode_Picture() are called for each picture.

In each call to Get_Hdr(), for each I picture, the file position is calculated and stored in d2v_current.position in the function picture_header(). For all pictures, the TFF/RFF flags and other data are also stored. In Decode_Picture(), when an I picture is seen (except the first one), the previously stored data is written out to the D2V file by calling WriteD2VLine() [or WriteGopLine() in earlier versions]. WriteD2VLine() reorders the information into display order and writes a complete line in the D2V file.

Note that in Decode_Picture(), when D2V_Flag is set, the picture is not actually decoded by calling picture_data(), because there is no need to actually decode the picture. Don't ask me why the original author put the indexing functionality in Decode_Picture()! It doesn't really matter.

At the end of the stream, ThreadKill() is called. This function flushes out the last D2V line, writes the trailer at the end giving FILM percent, and closes the file.

I haven't described the multilayered parsing system that supplies stream data to the decoder. That would require several hours to document properly.

[d'Oursse]

ok, thank you very much

And, I remember another question, that I forgot several days ago :
ptsdifference is always returning false (the cases where it returns true are commented) Is it normal ? If it really returns always false, as it is always called in tests, one can remove it.

[Guest]

Originally I used the return value. If the delay was too large, I didn't put it in the filename. But users wanted to see it in any case, so I commented out the bits needed so as to always include the delay value, no matter how big it is. You can't remove the calls to PTSDifference(), however, because that function writes the variable PTSDiff (it receives a pointer to PTSDiff via a function parameter).

[d'Oursse]

indeed. So, a call to PTSDifference is sufficient, right ? (without the if block)

Also, what's the difference between Frame_Rate and frame_rate (i want to give htem better names)

And is it necessary to create another thread for mpeg2dec ? Is it necessary for windows ? I don't see the need of it

[Guest]

indeed. So, a call to PTSDifference is sufficient, right ? (without the if block) Right.

Also, what's the difference between Frame_Rate and frame_rate (i want to give htem better names) The lower-case one is the actual value read from the MPEG stream. The upper case one may be different if Force Film is enabled:

Frame_Rate = (FO_Flag==FO_FILM) ? frame_rate * 0.8f : frame_rate;

And is it necessary to create another thread for mpeg2dec ? Is it necessary for windows? I don't see the need of it. The main window process must remain responsive to messages, so two threads are required.

[d'Oursse]

are the pat.[h/c] used for the creation of the d2v file ?

[Guest]

are the pat.[h/c] used for the creation of the d2v file ? Not directly. It's used by the "Detect PIDs" menu option to determine the transport PIDs. If you are not demuxing/decoding audio and you already know the video PID, or you require the user to determine and enter it some other way, then pat.* is not needed. But if you are demuxing or decoding audio, you'll need them to determine the audio type for transport streams, uness, again, you require the user to determine and enter that some other way.

[d'Oursse]

As, Donald does not want to talk to me anymore (because of a small sentence that he has misunderstod and upset him, which i really don't understand why, but it's his problem), I will not be able to finish that library in the little spare time that I have and without his help. I'll not work anymore on it.

regards

[Malphas]

That's unfortunate and disappointing.

[Guest]

I stand ready to answer any questions posed to me by anybody regarding DGIndex, so please don't try to make me a whipping boy. I never had anything to do with 'libd2v' and whether it ever does or does not exist.