Avidemux Forum

Avidemux => Main version 2.6 => Topic started by: poutnik on January 08, 2015, 07:22:51 AM

Title: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 08, 2015, 07:22:51 AM
I use current Win64 ADM 2.6.8  beta from DEC 4., aside of alternative processing chain of MeGUI/Avisynth.

I process exclusively DVB-T PAL SD MPEG2-PS material, with occasional PS corruptions.
They usually lead to slight audio shifts only, what ADM2.6 can usually managed by its fortunate timestamp approach. 
But sometimes ADM fails. being more picky than ProjectX, so I go via ProjectX + MeGUI ways.

Recently, I have tried ADM to process and remux ProjectX outputs MPEG2 M2V elementary stream + WAV audio stream.
As there is said ADM can read MPEG2 elementary stream

http://www.avidemux.org/admWiki/doku.php?id=using:cutting_mpeg_files (http://www.avidemux.org/admWiki/doku.php?id=using:cutting_mpeg_files).

But the opening trial of elementary stream has lead to ADM refuting, with message it cannot find demuxer for it ( like if could be demuxed ).
ES was correct, processed later fine by MeGUI DGindexer and OneClick procedure.

Is anything related corrupted in current ADM Win64 public compilations, or have I chosen incorrect procedure ?

BTW, what I like on ADM, compared to MeGUI, is convenience of the cutting.
I often choose batch  MPEG2 PS processing by MeGUI Oneclick.
Often even without PX, as documentaries are less critical than direct speech.
Then I do commercials cutting in final MP4/AVC/AAC in ADM on I-frames ( I do not insist of frame precission ).

Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: AQUAR on January 08, 2015, 12:12:05 PM
I don't think elementary streams are supported by ADM 2.6.
ADM 2.5 supports these and is usually a better option for working with MPEG2.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 08, 2015, 01:05:01 PM
Hmmm, good to know, it would not come to my mind that the feature could be removed (or rather not re-implemented yet ? )

I prefer ADM 2.6 due timestamp approach versus frame approach of ADM2.5 - what is  not needed anymore after ProjectX  A/V shift out-of-sync fixing.

Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 08, 2015, 03:21:45 PM
As ADM 2.5 alone, with frame approach,  is unusable for MPEG2 PS with occasional stepwise A/V out-of sync  issues .

Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: AQUAR on January 09, 2015, 02:00:01 AM
Yes - that is probably due to transmission errors causing frame drops.
ADM 2.5 won't do continuous resyncing.

I think You will need to use ProjectX.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 09, 2015, 01:11:48 PM
Yes, that is true.  But it is rather audio frame dropping, as audio content comes too soon, not too late.
But ADM 2.5 does not support - at least I was told so once - synchronized cutting of separated V and audio streams.

It is more handy to do All processing in MeGUI, or to make batch OneClick unattended MeGUI processing,
and then to do ADM MP4/AVC/AAV cutting at I-frames.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: AQUAR on January 10, 2015, 10:30:44 AM
I think it depends on what is being dropped as a result of packet losses/errors during transmission of the mpeg2-TS.
Since you mentioned you were processing mpeg2-PS, I presume that is by way of recording/remuxing that DVB.

Hence dropped video frames (GOP's) or audio samples.

Have you tried just remuxing the m2v + wav into MKV with bitstream timing correction (MKV toolnix) and see if ADM 2.6 is a usable option then? 
(don't know if it will help but I always try MKV toolnix as a fixit option).
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 11, 2015, 11:01:44 PM

It seems the audio frames are dropped, as PX fixes of videoframes are rare, but inserting of 5 audio frames  ( 120 ms ) is frequent.
As my first step is MPEG2 PS --> PX --> fixed M2V +WAV, I suppose mixing to MKV could help.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: Jan Gruuthuse on January 12, 2015, 06:33:44 AM
If you have the option? Try your recording in mpeg-2.ts instead of mpeg-2.ps. The same would go for mpeg-4.ps/mpeg-4.ts.

Other won't agree: do simple basic explanation is found here:
QuoteThe two major features of the Transport Stream are error checking/correction and stream synchronization. When they designed this system, they knew that data will be transmitted over wide distances over many kinds of cables, technologies and boxes. This exponentially increases the chances of error and corruption, not to mention signal degradation (loss of signal strength).

So, if program stream is a bull pen for domesticated animals, the Transport Stream is an iron cage for wild animals. It is far stricter, and stronger, overall. What do I mean by ââ,¬Ëœstrongerââ,¬â,,¢? To put it jokingly, if Program Stream faced Transport Stream in a boxing match, TS would win in the first round via knockout. That tough.

This robustness of the transport stream is one reason why it is widely used in terrestrial and satellite broadcast, even today. The MPEG TS is the container of choice for 90% of the worldââ,¬â,,¢s broadcast. No matter what you shoot in: RAW, H.264, HDCAM SR or film, your beloved content is converted and broadcast as MPEG-TS.
source: http://wolfcrow.com/blog/program-stream-vs-transport-stream-the-simple-difference/

If the audio shift is happening with AC3 audio track on computer? See if the audio shift is happening to, on other hardware media players like from usb stick on dvd player/flatscreen tv, STB, home serve DLNA capable?
Processing ac3 on computers does require more processing time/processor power: so it could happen this is a cause.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 12, 2015, 07:20:57 AM
@Jan Gruuthuse>  Hm, my understanding was, that my USB DVB-T  Leadtek DONGLE GOLD extract from VF signal TS anyway. I use SmartDVB for recording, offering both PS ( like mpg) and TS. I suppose the difference will be only, what is doing during TS-PS conversion SmartDVB, and what could eventually do ADM, if it can read it. Should I understand it as if I record to PS, ADM should read and decode it better, without need of fixing of damaged streams and A/V sync ?

Note that my MPEG2 PS SD recordings have exclusively MP2 audio.

I have not experimented with TS for a long time.
When I used original Leadtek application WinfastPVR2, it used to record to TS all the channels of the frequency, what I did not  like, and processing it was very inconvenient, as available tools were limited

AQUAR> , I can conveniently mux PX fixed MPEG ( m2v) + WAV into MKV vian MeGUI-mkvmerge mixing. BUT, while cutting in ADM is more convenitent for me than in MeGUI, batch processing is more convenient in MeGUI - dealing with job manager is less than optimal.

I agree it is looking for a Holy Graal to have an application, optimal in all aspects.   ;D
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: Jan Gruuthuse on January 12, 2015, 07:59:38 AM
Quote from: poutnik on January 12, 2015, 07:20:57 AM
@Jan Gruuthuse>  Hm, my understanding was, that my USB DVB-T  Leadtek DONGLE GOLD extract from VF signal TS anyway. I use SmartDVB for recording, offering both PS ( like mpg) and TS. I suppose the difference will be only, what is doing during TS-PS conversion SmartDVB, and what could eventually do ADM, if it can read it. Should I understand it as if I record to PS, ADM should read and decode it better, without need of fixing of damaged streams and A/V sync ?

Note that my MPEG2 PS SD recordings have exclusively MP2 audio.

I have not experimented with TS for a long time.
When I used original Leadtek application WinfastPVR2, it used to record to TS all the channels of the frequency, what I did not  like, and processing it was very inconvenient, as available tools were limited

TS recording should be the raw stream as it comes from DVB-T transmitter and TS recording would probably be the preferred way of doing so. ADM 2.6.8 win64 should be able to deal with these correctly. Make a test recording and see how it handles for you.
If there are issues with the mpeg-ts recording: not loading, not indexing correctly, ....
-Make a 1 minute recording of the channel(s) posing the problem. Upload it to publicly accessible website (like dropbox, ...)
- Post a new thread describing the issue(s) and include output from terminal window and provide a link to the uploaded file.
Time permitting the developer(s) could have a look at that issue, currently time is not abundant, so it could take a while.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 12, 2015, 01:06:07 PM
Generally, ProjectX is usually able to fix MPEG2 PS recordings, even if ADM2.6 breaks it teeth on that.
Should I suppose ADM reading transport stream will be as good as PX reading program stream .

Note that I did try/remember trying way of PX fixing TS.
I do it calling CMD batch ( MPG --> PX --> M2V + WAV
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: Jan Gruuthuse on January 12, 2015, 03:14:12 PM
It gets very confusing:
Quote from: poutnik on January 12, 2015, 01:06:07 PMI do it calling CMD batch ( MPG --> PX --> M2V + WAV
recording .mpg or mpeg-ps -> projectx -> m2v + wav?
Most likely:
Recording mpeg-ts -> ADM 2.6.8 (win64 from 2015-jan-11) -> cut commercials -> wanted container (probably mkv) keep video and audio codec.
Moving video between different programs probably causes issues, and developer(s) probably don't going to spend much time looking in to this.

DVB-T is already prone to interference. Weakening the available content by storing in .ps container is not much of a big help either.

So I provided you with all the available info from my side and leave you recording in mpeg-ps.

Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 13, 2015, 06:54:15 AM
Sorry to confuse you. 

My current recording until now was SmartDVB to MPG PS, as I was bad experience from past in TS processing.
Now I decided to switch to TS, as I realized it is easy in ADM - thanks for valuable info.

Processing mpeg-ps -> projectx -> m2v + wav was my way, if I used MeGUI path, or if ADM refuted to process MPG PS.

>> Recording mpeg-ts -> ADM 2.6.8 (win64 from 2015-jan-11) -> cut commercials -> wanted container (probably mkv) keep video and audio codec.

I resize and reencode on the purpose from MPEG2/MP2  to AVC/AAC to use Smartphone screen and fit its limited storage.

In my experience, moving video between programs does not cause issues. Issues are caused by data quality of DVB-T and of ADM itself.
As it was and is always easy to crash Win32/64 ADM 2.6. But I like ADM in spite of that.

I have always thought is is just matter if data are stored before TS2PS decoding  as TS, or after TS2PS decoding, as PS. As DVB-T is broadcast always as TS.  But perhaps not and I was wrong. I hope ADM can process any MPEG2 TS I will feed to it.

Anyway, thank you for your help.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: hinterwaeldler on January 13, 2015, 10:07:23 PM
Hi,

afaik DVB-? is always transmitted in MPEG2TS, at least as long as SD material is considered. ProjectX is able to restore the sync problems quiet well, as long as there is no change in the amount of audio channels within the stream. The later can be seen when take a look at streams containing ac3 sound. A good indicator is the switch between the regular program and the commercial in between. As long as the cutting only within these boundaries, projectX seems to works quite well.

A point which confuses me a little is the audio stream of your records. At least I've only seen mp2 and ac3 sound in my DVB-S2 records, but not sure, if DVB-T/T2 behaves different.

From my current experience working with TS in avidemux 2.6 works quite well (haven't tested ac3 sound for a while). If there should be some problems a prestep with projectx should help out, as it seems to be more robust
>> Recording mpeg-ts (direct stream to disk should fit) -> (projectX (optional step)) -> ADM -> cut/... -> wanted container/codec
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 14, 2015, 06:54:04 AM
I was initially used to DVB-T USB stick vendor software -Leadtek WinfastPVR2. It offered recording MPG TS, but it recorded there all the channel for given frequency.
So it was space consuming and no easy to process, as I was than not aware about PX a ADM TS reading abilities.

So I got than false impresion TS contains all stations, and a particular statios is extracted and stored in other format, like MPEG2 PS.

Aside of than, I though it does not matter if TS is saved before or after TS decoding.

Mediainfo says MPEG TS/PS contain MPEG audio version 1 Layer 2 = MP2, as MP3 is MPEG audio version 1 Layer 3 ( AFAIK )
PX can directly extract MP2, but there was occational problem with long movies, for there was reported incorrect MP2 length.
I have never noticed ACS audio in my recordings.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: Jan Gruuthuse on January 15, 2015, 07:20:31 AM
Some did made move already from MPEG-2 TS (Standard-Definition) Single Transport Stream to MPEG-4 TS (SD) Multiple Transport Stream and Generic Stream Encapsulation. You can put more channels in transmitter: dvb-t vs dvb-t2 / transponder dvb-s vs dvb-s2.
Users: don't confuse MPEG2 and MPEG4 (video encoding) with MPEG-2 TS and MPEG-4 TS (transport stream). Now did confuse myself, to early in the morning ... :-[
This is what I've should have written:
dvb-t = Single Transport Stream (TS)
dvb-t2 = Multiple Transport Stream and Generic Stream Encapsulation (GSE)

http://en.wikipedia.org/wiki/DVB-T2#System_differences_with_DVB-T
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 15, 2015, 08:00:41 AM
Providers in Czech republic still keep MPEG2 TS/ MPEG2 encoding for SD.
It is news to me there is MPEG-4 TS, I have thought MPEG 2/MPEG 4 specs share the TS format for both.

But
http://en.wikipedia.org/wiki/MPEG-4#MPEG-4_Parts (http://en.wikipedia.org/wiki/MPEG-4#MPEG-4_Parts)
Part 1  - ISO/IEC 14496-1

Describes synchronization and multiplexing of video and audio. For example the MPEG-4 file format version 1 (obsoleted by version 2 defined in MPEG-4 Part 14). The functionality of a transport protocol stack for transmitting and/or storing content complying with ISO/IEC 14496 is not within the scope of 14496-1 and only the interface to this layer is considered (DMIF). Information about transport of MPEG-4 content is defined e.g. in MPEG-2 Transport Stream, RTP Audio Video Profiles and others.[6][7][8][9][10]



Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: Jan Gruuthuse on January 15, 2015, 12:34:53 PM
I updated previous message to reflect what I intended to post.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: zakk on January 15, 2015, 02:24:21 PM
I've done lots of demuxing/muxing with mpeg-2+mp2/ac3 in .ts containers, And it has ALWAYS worked using ProjectX (demuxing+commercials cutting) + Avidemux 2.5.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: Jan Gruuthuse on January 15, 2015, 03:16:06 PM
And? Is anyone saying otherwise? Your choice, feel free to do so.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 16, 2015, 04:31:17 PM
ProjectX is sometimes is needed even for ADM and MPEG2 TS - verified.  My recordings suffer from occasional bursts of errors. I guess it may be from interfering electrical noise from nearby non compliant devices.  At such a burst point, ADM processing of MPEG2 TS ( MPEG 2 SD video )  sometimes fails to continue.

There is said in Projectx documentation that maximum of ProjectX fixing abilities are used in demux mode. If remuxing modes are used, fixing is weaker and some A/V out of sync may remain. So I used in past MPG demuxing mode of ProxectX for MeGUI processing.

While experiencing with TS these days, PX TStoTS fixing for ADM or MeGUI processing seems sufficient for me until now. ( unless Murphy's law says otherwise, hearing it ).

In past, I used MPG ProjectX demuxing to M2V and MP2(MPA). But, it occasionally suffered with MPA decoder issues for long common recoding of 2 adjacent movies.  So I then switched to demuxing to M2V + WAV, that was without problems.

This is the answer to one question above why M2V + WAV demuxing.


Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: Jan Gruuthuse on January 16, 2015, 07:52:50 PM
Quote from: poutnik on January 14, 2015, 06:54:04 AM
>8>8 DVB-T USB stick >8 >8
Small trick I use with USB modem: I use a short
Quote1 meter (3 feet) USB 2.0 A-Male to A-Female Shielded Extension Cable
to move usb dongle away from laptop and higher to improve reception of Mobile Internet.
This should work similar for DVB-T reception and if the dongle has signal strength meter, you could use it to find the best position for reception. Keep in mind, DVB-T has horizontal or vertical transmitter, 1/4 turn along axis of usb dongle could improve your receiving signal.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 16, 2015, 08:34:51 PM
I see, it is useful for local reception, indeed.
But I use centrally provided signal via coaxial cable from common receivers/amplifiers in block of flat.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: Jan Gruuthuse on January 16, 2015, 09:29:28 PM
If you know friend, knowledgeable in electronics, access to suitable oscilloscope, to check that signal and see if signal is clean enough? Was already in place for analogue TV reception? Could explain drops/errors in content. I've tried dvb-t here with digital dvb-t amplified antenna on roof. It was not workable: fluctuating signal strength and reception breakups. No joy viewing that. Now I have sat dishes (28.2Ã,°E, 23.5Ã,°E, 19.2Ã,°E, 16Ã,°E, 13Ã,°, 9Ã,°E and 4Ã,°E)  and only loose signal with heavy thunderstorms. At that moment the cable distribution network has the same issues.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 16, 2015, 11:16:13 PM
Quote from: Jan Gruuthuse on January 16, 2015, 09:29:28 PM
If you know friend, knowledgeable in electronics, access to suitable oscilloscope, to check that signal and see if signal is clean enough? Was already in place for analogue TV reception? Could explain drops/errors in content. I've tried dvb-t here with digital dvb-t amplified antenna on roof. It was not workable: fluctuating signal strength and reception breakups. No joy viewing that. Now I have sat dishes (28.2Ã,°E, 23.5Ã,°E, 19.2Ã,°E, 16Ã,°E, 13Ã,°, 9Ã,°E and 4Ã,°E)  and only loose signal with heavy thunderstorms. At that moment the cable distribution network has the same issues.

No, I do not not have any I know about. But even with osciloscope, I am not sure if he would recognize proper and unproper signal, unless he worked in TV broadcasting.
But as I have said, the  error patterns are rather like occasional bursts than random occurence.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: zakk on January 17, 2015, 09:16:29 AM
I use a TV software that gives me the signal's strength, very useful. Even in the center of a big city, everytime a start a recording I have to move the antenna to get the maximum quality, otherwise I can get an Avidemux crash while indexing. Try Pouchin TV.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 17, 2015, 11:05:00 AM
According to DVB-T original SW Leadtek WinfastPVR2 and SmartDVB ( which I like much more),  signal level is OK. And it should be, as antennas are on high roof of 8 floor building with direct visibility to 3 km distant transmitter, provided with antenna amplifiers.

Anyway, whatever reason for these bursts is,  it does not change the fact ADM has space for improvement in error recovery of input data from unreliable sources like DVB-T. Not everybody process perfect DVD/BR data from bought media, what ADM 2.5 may have supposed :-P.

Where ADM chokes, PX just "fixes film tape in place it got jammed in movie projector".  So, fixing is possible.

Such ADM ability would be useful especially for H264 records where ProjectX AFAIK is not applicable.
There is paid trialware Window alternative  for TS H264 dixing   TS-doctor (http://www.videohelp.com/tools/TS-Doctor) ( I have not tried it. )

QuoteMany modern satellite and cable receivers offer the ability to record television and radio programs by a so called PVR function. Such recordings are stored usually in the transport stream format (ts) or in a kindred format.

Unfortunately, such recordings often contain errors or incompatibilities that lead to incompatible recordings that can't be played back on other devices without problems.
Here, the TS-Doctor can help more than any other tool, for both SDTV and HDTV recordings. It verifies the recordings for errors, adapts the format to eliminate compatibility issues and cleaned up the recordings without changing the actual video and audio data.
In the end you will get a compatible transport stream (ts), that can be played easily on the computers or hardware media players such as popcornhour a100/110/c200, wdtv, xtream and many other similar devices.


Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: zakk on January 17, 2015, 12:05:21 PM
Yes if you can use it, Smart Cutter and TS muxer can also help.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: Jan Gruuthuse on January 17, 2015, 12:34:40 PM
There is a limit to missing flawed dvb stream information you can recover/fix. If the signal breaks up that is it. Mostly when the green blocks appear the content is to far gone.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 17, 2015, 12:48:05 PM
Quote from: Jan Gruuthuse on January 17, 2015, 12:34:40 PM
There is a limit to missing flawed dvb stream information you can recover/fix. If the signal breaks up that is it. Mostly when the green blocks appear the content is to far gone.

Yes, it is obvious there is limit, as for any data format. 
But usually the damaged part can be skipped at worst.
As where ADM cannot continue, PX usually can.
I say usually, but cases when PX gives up are very rare,compared to ADM.

IMHO ADM gives up too soon.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: zakk on January 17, 2015, 01:20:39 PM
Yes, and in my experience Some ADM releases give up soon er than others !! That's why I stopped using latest builds (now using r8195).
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: Jan Gruuthuse on January 17, 2015, 01:22:46 PM
We are back at the old road again: complaining about avidemux: I'm not interested.
It works fine for me. If there are issues, I pass it on to the developers. That's it.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 18, 2015, 08:33:08 AM
Quote from: Jan Gruuthuse on January 17, 2015, 01:22:46 PM
We are back at the old road again: complaining about avidemux: I'm not interested.
It works fine for me. If there are issues, I pass it on to the developers. That's it.

I apologize, it was not intended to be a complains, but topic for improvement.
You passed it and thats it.

Bad software would not be worthy to bother with.
If there is something I think could be better in good product,
should I be silent to prevent improvement ?

Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 18, 2015, 09:00:11 AM
For now, I have created a windows batch file that
        preventively fixes TS by ProjectX
        indexes fixed TS by CLI launched ADM QT4.

So I start ADM GUI session with preventively fixed and indexed TS.

As in case of a problem with occational nonrecoverable data error in original TS,
they often do not occur early in indexing phase, but in the middle of X264 encoding, making the effort wasted.

Early caution is better than late sorry.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 18, 2015, 09:06:35 AM
Quote from: Jan Gruuthuse on January 17, 2015, 01:22:46 PM
We are back at the old road again: complaining about avidemux: I'm not interested.
It works fine for me. If there are issues, I pass it on to the developers. That's it.

Unless there are improvement suggestions from users or coders/authors themselves, there is no development, as all are satisfied.

But  I agree the form they are presented is very important.
The same thing may lead to both being implemented or rejected, depending on how it is communicated.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: AQUAR on January 18, 2015, 10:05:10 AM
@ poutnik

The "back on the old road" issue is not so much about You raising and discussing issues with ADM.
But more to do with some individuals that always jump in to try and agitate these discussions about ADM issues (maybe unintended!).

IMHO these individuals should do better by being constructive in the discussion.

ADM has its flaws, as has every video editor (none meets the "holy grail").
It is what it is, and improvements do come about by topics such as this.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 18, 2015, 11:20:33 AM
I see.
I like to discuss with you, and I hope my suggestions may lead sometime to be considered.

If ADM developers do not consider to improve error recovery of ADM - what I can understand,
they may consider integration of ProjectX ( as java application it is mutiplatform ) as external tool for optional data preprocessing.

Or as a fallback step if direct processing of MPEG2 PS/TS by ADM fails.

One can do it manually by launching linux scripts or Windoes batch files, but done directly from ADM GUI would be great.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: AQUAR on January 19, 2015, 11:35:18 AM
@ poutnik
I too am just an enduser and so, of course, I cannot speak for ADM developers as to how they will shape the future of ADM.
But ADM being open source means that feature enhancements can be made by anyone with the needed skill sets.

As a recent example, X265 was added by KoolAidMan with the support of the ADM Author.
That example also was by way of some members here suggesting it woud be nice to have that feature.

On top of that, the Author (primary developer) of ADM is a very frequent visitor here.
Meaning all suggestions and issues are actually being read and therefore at least get an in passing consideration.

I have exercised the freedom to speak my meaning about ADM and its not all about glory either.
My personal opinion (not sanctioned by the ADM people!)(and obviously opposed by some!):
Like some endusers that frequently respond here, I hate it when users push beyond the discussion/wishing/reporting boundary.
Hate it because no enduser has self entitlements to make fix it demand's that involves the skill's and time of others.
Especially so, if those that make "demanding suggestions" have no concept of what is involved.
And I get peeved even more by those members that try to steer the discussion into a kind of "lets complain about ADM" nonsense.

I remember some time ago and enduser wanting a full diagnostic report generated on every ADM crash!
Tried to explain how unreasonable that type of "request" is (wasted effort that was!).

Anyway, I enjoyed this thread.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 19, 2015, 01:36:00 PM
Well, my last real coding was CP/M M80 Assembler used for Z80 CPU , some CP/M Pascal and C, and Turbo Pascal for DOS. Since then, I do usually just only some simple batches, very simple Linux scripts, simple VBS or javascipt and some not so simple MS Excel VBA coding.

I hope my suggestions do not cross demanding level, and if felt like that, it was not my intension. I am just struggling to understand sometimes, why are some particular things implemented by their way.

Like ADM not expecting the user may want the original video MyGreatVideoRecord.TS  to be saved as ( or derived) "MyGreatVideoRecord" filename, with "MKV" extension if he has chosen MKV container.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: Jan Gruuthuse on January 21, 2015, 02:38:01 PM
some additional info:
SD transmissions in mpeg-ts, dvb-s2 are not handled very well in avidemux 2.5.6.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 21, 2015, 05:08:02 PM
Yes, I remember seeing that.  Thank you for mentioning it.
I do not process HD H264 based TSs, just SD MPEG2 TS.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: Jan Gruuthuse on January 21, 2015, 05:15:36 PM
No No: not HD H264 based TS, now SD H264 based
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 21, 2015, 09:07:20 PM
Hm, I did not know SD context is broadcasrt as H264 as well.
Our providers use it for HD only.

In fact, I am not fully sure if all DTV sets are able to process H264...
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: Jan Gruuthuse on January 22, 2015, 12:48:42 AM
http://en.wikipedia.org/wiki/DVB-T2
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: poutnik on January 22, 2015, 05:42:04 AM
Hmm, yes, I remember reading this articles. We use DVB-T only here AFAIK, H264 only for HD.
I did not find explicit mentioning SD H264 there, but impkictly perhaps involved.
Title: Re: Processing + muxing of MPEG2 elementary video stream
Post by: Jan Gruuthuse on January 22, 2015, 06:13:28 AM
QuoteAs of 2014, it was implemented in broadcasts in the United Kingdom (Freeview HD, eight channels across two multiplexes, plus an extra multiplex in Northern Ireland carrying three SD channels), Italy (Europa 7 HD, twelve channels), Finland (21 channels, five in HD), Sweden (five channels),[1][2] Thailand (41 SD, 9 HD channels)[3] Flanders (18 SD Channels), Serbia (ten SD and HD version of the public broadcasterââ,¬â,,¢s channel RTS),[4] Ukraine (32 SD and HD channels in four nationwide multiplexes), Croatia (two pay-TV multiplexes), Denmark, and some other countries.

QuoteIt was expected that over time there would be enough DVB-T2 receivers sold to switch all DTT transmissions to DVB-T2, and H.264.

Very unhappy wording, somewhat in between the lines. I would explicit mention SD H.264