DGAVCDec 1.0.9 [Archive] - Page 24

View Full Version : DGAVCDec 1.0.9

Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 [24] 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

Deinorius

17th July 2008, 20:13

First 1, then 3 imho. :)

Ranguvar

17th July 2008, 20:14

2, 3, and MKV support :)

rebkell

17th July 2008, 20:27

I haven't tried with a newer version of DGAVC, but will it be able to read the captures of the Hauppauge HD-PVR? Here is a link to a page that has a couple of samples captured on it:

http://blog.arogan.com/2008/06/hauppauge-hd-pvr-model-1212.html

Search for hdpvr-def.zip and you'll find a link to some short clips he captured with the machine.

Guest

17th July 2008, 21:02

I haven't tried with a newer version of DGAVC, but will it be able to read the captures of the Hauppauge HD-PVR? I tried one of them and it worked fine. It was Fields (TFF) but encoded in a way that libavcodec.dll is happy with. The only thing to watch out for is that you need to enable GOPs (IDRs) for capture, and the more frequently you have them, the faster will be your random access.

I've asked my boss to buy one for us. :)

rebkell

17th July 2008, 21:13

I tried one of them and it worked fine. It was Fields (TFF) but encoded in a way that libavcodec.dll is happy with. The only thing to watch out for is that you need to enable GOPs (IDRs) for capture, and the more frequently you have them, the faster will be your random access.

I've asked my boss to buy one for us. :)

Great, I guess I need to update my DGAVCDec then :o

Turtleggjp

18th July 2008, 00:04

My immediate plans are:

1. Cutting (multiple ranges, not just one).

2. Address libavcodec deficiencies.

3. MP4 support.

What would you like to see?

For me, the biggest help would be #2 (as you may have seen from my video camera's samples). After that, I can handle #1 with AVIsynth if I need to, and I would vote for MKV support over MP4 support.

Oh, and if it's not too much trouble, maybe a command line switch to disable writing of the delay in the audio file's name. My automated process will not work now because it cannot predict the names of the output audio files. :thanks:

elguaxo

18th July 2008, 00:30

I would vote for MKV support over MP4 support

same here. thanks!

rebkell

18th July 2008, 00:40

My immediate plans are:

1. Cutting (multiple ranges, not just one).

2. Address libavcodec deficiencies.

3. MP4 support.

What would you like to see?

I don't suppose #1 would include audio also, would it? That would be total nirvana. :)

Atak_Snajpera

18th July 2008, 00:47

mkv and mp4 support seems to be useless since we have FFmpegSource()

Guest

18th July 2008, 01:14

mkv and mp4 support seems to be useless since we have FFmpegSource() Does it support accurate random access?

Revgen

18th July 2008, 01:45

Does it support accurate random access?

I don't know for sure, but the best seek method (seekmode=0) is alot more accurate than DirectShow.

Unfortunately, the method that is done is much slower than DGAVCDec. It's also full of other codecs and stuff that have nothing to do with H264.

I would prefer MP4 support from DGAVCDec over FFMPEGsource.

EDIT

Here are the seekmodes as described in the FFMPEGSource manual

seekmode: Force how seeking is handled, has no effect on matroska files which always use the equivalent of seekmode=1
-1: linear access without rewind, will throw an error if each successive requested frame number isn't bigger than the last one, only intended for opening images but might work on well with some obscure video format
0: linear access, the definition of slow but should make some formats "usable"
1: safe normal, bases seeking decisions on the reported keyframe positions
2: unsafe normal, same as 1 but no error will be thrown if the exact destination has to be guessed
3: aggressive, seek in the forward direction even if no closer keyframe is known to exist, only useful for testing and containers where avformat doesn't report keyframes properly

lchiu7

20th July 2008, 09:11

That audio is AAC LATM/LOAS. I don't support that yet, and I can't predict when I may get to it.

Any idea how hard it would be to at least be able to output that audio stream as wav? This audio format is now being used by some DVB-T broadcasters and it would be great to be able to convert the audio to something that is more generally playable. Would this help?

http://blog.monogram.sk/janos/2008/03/15/monogram-aac-decoder-0930/

Thanks

Update: When priorities permit just being able to output AAC-HE LATM/LOAS in its native stream would be good. We can find tools to process it after it comes out. Thanks

lchiu7

20th July 2008, 09:22

@Mboufleur: You can demux all the streams with TSRemux. The "MPEGaudio"-files you have to rename *.aac. Winamp is able to play these files and also to convert them to Wav-files. Thus you could e.g. reencode them either to real MPEG-audio or to AC3 and then remux these audiofiles back with TSMuxer.

In the meantime I have downloaded one full sample video. Using TSRemux I demuxed the video- and the audio-stream as avc- and aac-file resepctively. The aac-file I converted into a stereo-wav-file using Winamp with its file-output-plugin. Then I encoded this wav-file with Belight using the AC3enc-encoder into a stereo AC3-256kbit-file. Opening the original "mpg"-ts-file with a hex editor I searched for the first PTS-value of the video stream which can be found if you search for the first occurence of the video flag string "00 00 01 E0" and then the five bytes of the PTS value which is located with a 5 bytes offset after the video flag. In the first sample it is "31 00 CD 33 9D". Then you have to search for the first PTS-value of the audio stream which can be found if you search for the first occurence of the MPEG-audio flag string "00 00 01 C0" and then the five byted of the PTS value which is located with a 5 bytes offset after the MPEG-audio flag. Here it is "21 00 C7 F1 91". As these values are different you have to calculate the time offset so how many seconds the audio is playing too early in this case as the audio-PTS is smaler than the video-PTS, as the least significant bit of the first byte of the PTS values can be ignored so that the "31"-value is equal to the "21"-value of the different PTS-values. As the calculation of the PTS values which is documented in the MPEG ISO standards is quite complicated I have written a simple VideoPTS-Calculator programme:
http://www.alice-dsl.net/schmendrick/VideoPTSCalc.exe
which uses .NET-2.0. You can enter the video PTS-value as the ASCII-string of the hex values of the first five bytes "21 00 CD 33 9D" in the left input box, then guess the time offset value (shift(sec)) in seconds e.g. "-0.82211" which is -822.11 milliseconds, then click on "compute" and obtain the audio PTS value in the right box "new VideoPTS". If you experiment a little with the "shift(sec)"-value you are able to find the exact offset value.

Then using TSMuxer you can remux the avc-video file with your new AC3-audio file using the time offset value in this case -822 milliseconds to obtain a perfectly synchronous ts-file which can be properly displayed e.g. using PowerDVDUltra.

I hope this method works for you. You can contact me if you have problems.

Schmendrick

Hi I got quite excited when I read this post since it seemed to be a way to convert the DVB-T broadcasts in NZ which use H.264 video and AAC-HE LATM audio to something more accessible. I used tsmuxer to separate the streams but I cannot even play the AAC files in winamp, let alone output them as wav files. This is winamp 5.54

Winamp reports the right length in time but as soon as I press play it stops.

Are you able to try your process on files on this page and report your experiences?

http://www.geekzone.co.nz/Fossie/4877

Thanks

amango

20th July 2008, 11:26

I used Alpha 26 with success on many DVB S2-TS streams.

Since Alpha 28 I have always a audio delay after muxing the new encoded video. If I save a project, the audio delay on the demuxed ac3/mp2-file is the same with both versions (listed in the file name, for example "DELAY -1152"), but only the demuxed audio file from Alpha 26 is in synch with the new encoded video.

canTsTop

20th July 2008, 19:20

My immediate plans are:

1. Cutting (multiple ranges, not just one).

2. Address libavcodec deficiencies.

3. MP4 support.

What would you like to see?

is this cutting will be frame accurate (like Trim command in Avisyth)? is it include audio cutting to? it would be incredible!

Address libavcodec deficiencies would be most important for me.

Also Audio delay support in avs template :)

One more future i would like to see: is possibility to specify location of libavcodec.dll in dga file for portability reasons. i like to keep my all avisynth plugins and other tools in tools directory:
loadplugin("tools\DGAVCDecode.dll")
loadplugin("tools\NicAudio.dll")
or mybe DGAVCDecode.dll should also look for libavcodec.dll in same directory from where DGAVCDecode.dll was loaded.

thank you

SeeMoreDigital

20th July 2008, 19:34

I would prefer MP4 support from DGAVCDec over FFMPEGsource.Me too...

Especially as MPEG-4 AVC video and the .MP4 container derive from the ISO/IEC 14496 specification.

audyovydeo

20th July 2008, 21:42

I would prefer MP4 support from DGAVCDec over FFMPEGsource.

Adding one more vote to this motion.

cheers
a/v

Guest

20th July 2008, 23:45

Schmendrick

21st July 2008, 15:08

Hi I got quite excited when I read this post since it seemed to be a way to convert the DVB-T broadcasts in NZ which use H.264 video and AAC-HE LATM audio to something more accessible. I used tsmuxer to separate the streams but I cannot even play the AAC files in winamp, let alone output them as wav files. This is winamp 5.54

Winamp reports the right length in time but as soon as I press play it stops.

Are you able to try your process on files on this page and report your experiences?

http://www.geekzone.co.nz/Fossie/4877

Thanks

@Ichiu7:
I am using Tsremux to demux the aac-stream which is indicated as "MPEG audio stream" by Tsremux even though it is an AAC-HE-stream. Using Winamp version 5.5 I am able to decode all but one of the indicated HD-sample streams.
The sample-clip called "Freeview HD sample" is corrupt an cannot be remuxed or played by any programme I have tried.
Looking at the hex code of this ts-file also no recognizable stream flags can be found.

May be you just attempted to open this file.
Nevertheless the only programme which is able to play
these AAC-files is Winamp.

Schmendrick

Guest

21st July 2008, 16:36

Guys, please stay on topic. Use of TSREMUX belongs elsewhere. Thank you.

lchiu7

21st July 2008, 22:30

@Ichiu7:
I am using Tsremux to demux the aac-stream which is indicated as "MPEG audio stream" by Tsremux even though it is an AAC-HE-stream. Using Winamp version 5.5 I am able to decode all but one of the indicated HD-sample streams.
The sample-clip called "Freeview HD sample" is corrupt an cannot be remuxed or played by any programme I have tried.
Looking at the hex code of this ts-file also no recognizable stream flags can be found.

May be you just attempted to open this file.
Nevertheless the only programme which is able to play
these AAC-files is Winamp.

Schmendrick

Getting back OT. I was able to use dgavcindex (not sure which version - possibly Alpha 26) to extract the audio from a DVB-T stream captured recently, so production broadcast. The output file created has a suffix of mpa. One filename also had delay -335ms in it so I assumed that dgavcindex thought that this was delay in the audio.

But after renaming the file to aac suffix, playing it in winamp to get a wav file and converting it to AC-3 when muxed back with the video dgavcindex created in the first step, there was a 1s delay in the audio. When I inserted 1s as the delay in the mux back step the resultant file played fine.

Need to do further testing to see if this is a consistent delay or variable based on the file. It certainly wasn't related to the delay as noted in the filename.

Happy to provide or link to samples for testing

Pookie

22nd July 2008, 04:43

I'm voting for addressing issues with libavcodec. Lots of AVCHD owners out there unable to send their newborn's first burp video to the in-laws because of the more recent file formats.:D (Not completely the case - they can use DirectShowSource instead)

amango

22nd July 2008, 10:25

Please post a link to a source stream fragment that I can use to duplicate the issue.

http://rapidshare.de/files/40050488/Sample.ts.html

There are 3 audio streams - use "40". I demuxed it with Alpha 26 and Alpha 28 and made an Xvid video out of both.

The video from Alpha 26 is in synch.
The video from Alpha 28 is out of synch (+400 ms ?).

I know this is a bad sample (a dancing scene) - but watch at 00:43 between a scene change. The last word of the woman ends before the scene changes (encoded Alpha 26-video). In the Alpha 28-video the last word can be heard over the next scene.

Both versions are reporting the same delay but only Alpha 26 is in synch.

Guest

22nd July 2008, 13:37

Both versions are reporting the same delay but only Alpha 26 is in synch. Are you sure about that?

I tried both versions on audio ID 40. They both served 3220 frames starting with the same frame via the Avisynth script, and the demuxed audio files were bit-for-bit identical. Are you sure you used the same script and encoding for both cases? If so, give me your script. I'm thinking you must have forgot to adjust for the audio delay when using alpha 28.

amango

22nd July 2008, 14:56

This is my script:

avcsource("%source_file%",deblock=true)
LanczosResize(720,576)
Assumetff().SeparateFields().SelectEvery(4, 0, 3).Weave()
tdeint()
degrainmedian()
undot()
Limiter()

I encode the audio with Besweet (128 KB VBR) and mux audio and video together with VirtualDubMod.

Every video I tried gives me a delay with Alpha 28, but not with Alpha 26. Don't know why.

Guest

22nd July 2008, 15:00

Where are you adjusting for the audio delay?

Do what I did: Make the project with both versions. Then serve the AVS script into VirtualDub and check that the starting frame and number of frames is the same for both. Then compare the audio files to see if they are identical. You'll see that the video and audio are identical coming out of both versions. Therefore, it must be something in your subsequent process that is going wrong.

Guest

22nd July 2008, 15:07

Regarding your script:

The sample is progressive with every frame duplicated. So you can just do:

SelectEven()

I don't understand the point of your script. You're resizing before deinterlacing and the Assumetff().SeparateFields().SelectEvery(4, 0, 3).Weave() line makes no sense to me for this sample. That's generally used when reinterlacing after bobbing.

amango

22nd July 2008, 15:12

G_M_C

22nd July 2008, 15:30

I just copied this script from one user from videohelp.com who wanted to convert 720p50 to SD.

I really don't know why. I am using "DVX" (from Stax) for years now.

Usually I do this all the time to encode videos:
I start DGIndex or DGAVCDec - Save a project. Then I drop the index file from your programs to DVX. DVX recognites the delay from the audio file name. I cut the video and start the encoding process. DVX uses Besweet and starts VirtualDubMod to mux the video.

Soon after I updated to Alpha 28, I got this delays in my files. Reverting back to Alpha 26, they were all in synch again.

I will try it again manually as you said.

The strange thing with your script is that you interlace first, and than try to de-interlace again. That makes no sence.

720p50, are you shure it is 720p50 ? If so, try to load the clip plainly (only with the AVCSource-line) into VDub. Slowly walk through a reasonable portion of the clip, and find out it there a frame-duplicates (and)or frame-blends.

If the original (unblended/unduplicated) frames occur on the even frames use "SelectEven()" use SelectOdd() when those frames occur on the odd-ones. Then put the line "AssumeFPS (25,1,True)" and see if the whole clip still syncs with your audio.

Guest

24th July 2008, 03:23

1. Implemented project range selection, i.e., the [ and ] buttons are now functional.

2. Revised popup error/warning handling so that individual error types can be selectively suppressed.

http://neuron2.net/dgavcdec/dgavcdec.html

Currently, only a single range is supported, as in DGIndex. I want to get feedback on that before attempting to support multiple ranges, which is very difficult.

Note there are bugs in the Windows trackbar for themed desktops. To work around it, I enabled the ticks bar as well. Either the ticks bar or the main trackbar will show your selection range, depending on your OS and desktop settings. I haven't yet found a clean solution, short of implementing my own trackbar (as Avery does in VirtualDub; I'm not that masochistic :)).

rebkell

24th July 2008, 04:20

Guest

24th July 2008, 04:25

Thanks for the feedback.

Please re-download alpha 29, as I just fixed a bug that prevented you from doing > or playing past the ] position. Only preview and save project should honor the ] position.

lchiu7

24th July 2008, 07:05

I know you don't support LATM/LOAS audio streams in .ts files but dgavcindex certainly knows they are there when you do Detect PIDS and occasionally they show up when you do Audio Demux.

How hard would it be to implement limited support - i.e. recognise the streams correctly and allow them to be demuxed from the H.264 video? On occasions I have been able to demux them from some files and convert to wav using winamp, on other occasions while there is audio in the file (same format) dgavcindex doesn't see any audio at all.

Don't need to have convert to wav which I guess would be more work to implement.

Thanks

Guest

24th July 2008, 14:42

How hard would it be to implement limited support - i.e. recognise the streams correctly and allow them to be demuxed from the H.264 video? On occasions I have been able to demux them from some files and convert to wav using winamp, on other occasions while there is audio in the file (same format) dgavcindex doesn't see any audio at all. Can you provide a sample of one file that you can demux from and one that you cannot using DGAVCIndex, and for which both use the same format?

lchiu7

24th July 2008, 21:13

Can you provide a sample of one file that you can demux from and one that you cannot using DGAVCIndex, and for which both use the same format?

This one can be demuxed but it loses the first 6-7 seconds

http://www.datamix.info/one news aac_.edit.ts

This one cannot be demuxed or shows no audio at all

http://www.datamix.info/One audio.ts

They are about 18mb and 35mb in size - trust that is not an issue

Thanks

Guest

24th July 2008, 22:31

Please fix your links. They're not working and I'm not in the mood to play guessing games. Thank you.

LoRd_MuldeR

24th July 2008, 22:36

Wasn't too hard to guess :D

http://www.datamix.info/one%20news%20aac_.edit.ts
http://www.datamix.info/One%20audio.ts

lchiu7

24th July 2008, 22:54

Wasn't too hard to guess :D

http://www.datamix.info/one%20news%20aac_.edit.ts
http://www.datamix.info/One%20audio.ts

Thanks! I cut and pasted from the browser and didn't realise that this BBS doesn't parse the URL properly and I should have put in ASCII values for blanks!

Guest

24th July 2008, 23:09

Wasn't too hard to guess I didn't say it was hard. I said I was not in the mood. :devil:

I'll have a look at them and let you know.

CruNcher

24th July 2008, 23:25

Donald might be a strange question but do you have the time and will to help the Avidemux guys with their M2TS AVC parsing/indexing ? at least could you take a glimpse @ the source of the parser/indexer and give a advise :) ?

http://bugs.avidemux.org/index.php?do=details&task_id=467

Guest

25th July 2008, 00:37

What language is Avidemux implemented in?

Are they trying to duplicate the functionality of DGAVCDec? I don't mind, but I can tell you it is hard. It's not something you can just crank out. It needs a sustained attack and a lot of non-obvious heuristics to make AVC random access work. If they are trying to duplicate DGAVCDec functionality, I can just give them my source code. If not, then what are they trying to do? Bear in mind, I know nothing about Avidemux.

LoRd_MuldeR

25th July 2008, 00:57

It's written in C++ and the MPEG PS/TS/ES demuxer can be found here, I think:
http://svn.berlios.de/wsvn/avidemux/branches/avidemux_2.4_branch/avidemux/ADM_inputs/ADM_mpegdemuxer/?rev=4275&sc=1#_branches_avidemux_2.4_branch_avidemux_ADM_inputs_ADM_mpegdemuxer_

BTW: Avidemux creates index files to implement random access, similar (but most likely not identical) to DG(AVC)Index...

Guest

25th July 2008, 01:20

So where is the problem, in the M2TS parser or the AVC indexer? Let me try to find that out by asking these questions:

1. Does an MPEG2 elementary stream inside an M2TS transport stream open, and indexing works correctly?

2. Does an AVC elementary stream (not in M2TS) open, and indexing works correctly?

3. Is it just AVC elementary in M2TS that goes wrong?

Guest

25th July 2008, 01:28

On occasions I have been able to demux them from some files and convert to wav using winamp
This process works with the first file you linked. So I should be able to support demuxing LATM/LOAS. I'll just start outputting it at a TS packet with tranport_unit_start_indicator set, and hope for the best. I didn't do it before because I didn't know how to parse for the audio sync word.

I wasn't aware that Winamp had an output plugin!

LoRd_MuldeR

25th July 2008, 01:45

I think Avidemux can handle both, MPEG-2 and AVC, from Transport Stream. Elementary AVC doesn't work to my experience.

One of the biggest problems in Avidemux is frame-accurate access to AVC in general, no matter what container (MP4, AVI, MKV, TS).
Avidemux switches to a "special" mode for AVC video and then you loose frame-accuracy, because the decoder will buffer a number of frames "internally" in that mode.
When you seek forth and back, the same frame# doesn't necessarily show the same picture.

I think this is more a problem in the decoder part than in the indexing part. But MEAN or Gruntster might answer this more accurately.
If I remember correctly, then MEAN said once that "frame reordering" (???) for AVC is not implemented properly yet and that it's very hard to do...

Guest

25th July 2008, 02:12

Then it sounds like a long, involved job to fix that for Avidemux. I have my hands full with DGAVCDecode. If it was just a little problem in the M2TS parsing that would be another matter, although I note that all the M2TS parsing hacks in there are prefixed with "FIXME" comments. :)

Soon I will release source code for DGAVCDec, at which point the method for indexing and random access of AVC will be available for re-use. The biggest complication is ensuring that the needed SPS/PPS's are available and injected when needed.

LoRd_MuldeR

25th July 2008, 02:20

I found this quote:

For mpeg 1/2/4, avidemux know the frame type in advance and can handle the decoding /frame ordering logic
For h264 in most case it cannot and let the codec decides
As a result it does not know the frame type beforehand, but only after decoding the frames
BUT, the decoded frame can pop out a long time after it has been fed to the decoder
[...]
The simple one (like mpeg1/2/4) will not work due to the pyramid b frame ordering

Guest

25th July 2008, 02:30

I implement a clever solution to that issue. :)

rebkell

25th July 2008, 03:56

I have a question about demuxing the video stream and the extension. I think you give it an avc extension, is there any difference between .264, .h264 and .avc? I use megui and it is looking for .264 as an extension for the muxer. There isn't anyway to tell DGAVCIndex to create a demuxed video stream with a different extension, is there? I just renamed it, is there any significance to the avc extension?

Guest

25th July 2008, 04:07

is there any difference between .264, .h264 and .avc? I suppose some applications might require certain extensions.

I use megui and it is looking for .264 as an extension for the muxer. Silly megui.

There isn't anyway to tell DGAVCIndex to create a demuxed video stream with a different extension, is there? There is no way as currently implemented.

is there any significance to the avc extension? I like it.

If renaming is really a big issue for you, I could implement an INI file option to allow you to specify the extension to be used.