VideoHelp Forum
+ Reply to Thread
Results 1 to 27 of 27
Thread
  1. Hi,

    I was wondering if anyone here is working with UK "Freeview HD" recordings in Linux, and if so, which tools/workflows are working?

    Video is 1440x1080i H.264 level 4.0 and audio is AAC in LATM.

    I've tried tsmuxer, but this doesn't recognise the audio track.

    I would like to remux them to a format playable on the PS3, and also a format accepted by Apple's mediafilesegmenter for http live streaming (HLS) to an ipad/iphone (or equivalent open-source segmenters).

    I've many years Linux DVB/MPEG-2 experience (I'm the author of dvbstream and dvbtune), but am struggling to find a way to make use of recordings from my newly purchased DVB-T2 card.

    Thanks.
    Quote Quote  
  2. ffmpeg should be able to remux the content to mkv or mp4.
    Quote Quote  
  3. Originally Posted by Selur View Post
    ffmpeg should be able to remux the content to mkv or mp4.
    Thanks for the reply. If only it was that simple...

    Trying to use ffmpeg on the original transport streams (e.g. ffmpeg -i input.ts -acodec copy -vcodec copy output.mp4) fails with an error related to the audio stream:

    Code:
    [mp4 @ 0x1bad840] track 1: could not find tag, codec not currently supported in container
    ...
    Output #0, mp4, to 'ffmpeg.mp4':
      Metadata:
        encoder         : Lavf53.32.100
        Stream #0:0: Video: h264 (![0][0][0] / 0x0021), yuv420p, 1440x1080 [SAR 4:3 DAR 16:9], q=2-31, 27.46 fps, 90k tbn, 90k tbc
        Stream #0:1(eng): Audio: aac_latm ([17][0][0][0] / 0x0011), 48000 Hz, stereo
    Stream mapping:
      Stream #0:0 -> #0:0 (copy)
      Stream #0:1 -> #0:1 (copy)
    Could not write header for output file #0 (incorrect codec parameters ?)
    It has also mis-detected the video FPS (it's 25 frames per second).

    The most progress I've made is with a combination of eac3to for demuxing, a tool called "LOAS_LATM_to_ADTS.exe" to convert the demuxed audio stream to ADTS format, and then either MP4Box or tsmuxer to remux the streams.

    However, neither of these files are playable on my PS3 - the PS3 fails to recognise the audio stream in the TS version, and recognises (displaying the correct stream info) the audio stream in the MP4 version but just gives silence.
    Quote Quote  
  4. Member yoda313's Avatar
    Join Date
    Jun 2004
    Location
    The Animus
    Search Comp PM
    I don't know if it will help or not but you could try remuxing the video and audio into a m2ts file. The ps3 will also read that file type for h264 video.

    It might be worth a test just to see if it would work. Strange that you'd have different behavior from the same audio/video in different file types.

    Have you tried converting the audio to ac3 or aac?
    Donatello - The Shredder? Michelangelo - Maybe all that hardware is for making coleslaw?
    Quote Quote  
  5. Also would be cool if you could upload a small sample (< 30sec) of such a file somewhere,...
    also try something like: ffmpeg -i input.ts -r 25 -acodec aac -vcodec copy - output.mp4
    Quote Quote  
  6. Hi,

    Thanks for the responses. I've tried m2ts and that gives identical results to plain ts - the PS3 doesn't recognise the audio track. I'll keep experimenting though...

    I've attached a 30 second sample recording from BBC One HD.

    If anyone can convert (preferably without re-encoding anything) this for playback on a PS3 or iPad/iPhone, I would be very grateful for tips!

    Thanks.

    EDIT: I've tried converting the audio to AC3, and that works on the PS3 in TS but not in MP4. In MP4, the codec type is recognised, but I get silence (same as AAC audio).

    My MP4Box command-line is simply "MP4Box -add video.h264 -add audio.ac3 test-ac3.mp4"
    Image Attached Files
    Last edited by 4candles; 17th May 2012 at 04:55.
    Quote Quote  
  7. didn't think about the latm thing,..
    (or better: I thought the problem was fixed, but it occurs the 'fix' was removed from ffmpeg, again see: http://ffmpeg.org/trac/ffmpeg/ticket/320)

    afaik the only application capable of extracting an latm codec aac stream to an adts aac stream is vlc
    so you would need to:
    1. extract the audio
    Code:
    vlc.exe -I dummy "Path to output.aac" --sout #std{access=file,mux=ts,dst="Path to input.ts"} vlc://quit
    2. remux the video to mp4
    Code:
    ffmpeg -i "Path to input transport stream" -an -vcodec copy - "Path to output.mp4"
    3. add the extracted audio the video stream
    Code:
    MP4Box -add "Path to output.aac" "Path to output.mp4"
    In theory step 2&3 could both be done together in ffmpeg, but since ffmpeg had problems creating valid mp4 files in the past, I would stick with MP4Box for muxing.

    Cu Selur

    Ps.: also read: http://forum.doom9.org/showthread.php?t=157467
    PPs.: since I'm unsure if ipad can handle mbaff coded aav content, reencoding the whole thing is probably the best way to go.
    Last edited by Selur; 17th May 2012 at 06:26.
    Quote Quote  
  8. Member
    Join Date
    Oct 2010
    Location
    England
    Search Comp PM
    Originally Posted by Selur View Post
    PPs.: since I'm unsure if ipad can handle mbaff coded aav content, reencoding the whole thing is probably the best way to go.
    Mediainfo is reporting the AAC profile/level as "High efficiency AAC@L2". The PS3 compatibility page says the only AAC format it supports is AAC-LC, so the audio might need to be converted as well.
    Quote Quote  
  9. Originally Posted by intracube View Post
    Originally Posted by Selur View Post
    PPs.: since I'm unsure if ipad can handle mbaff coded aav content, reencoding the whole thing is probably the best way to go.
    Mediainfo is reporting the AAC profile/level as "High efficiency AAC@L2". The PS3 compatibility page says the only AAC format it supports is AAC-LC, so the audio might need to be converted as well.
    There are two audio streams in the file - the first should be approx 128kbps AAC-LC (the main audio) and the second is approx 64kbps AAC-HE (audio description). Compatible Freeview HD receivers decode and mix both audio streams when the user enables audio description.
    Quote Quote  
  10. Member
    Join Date
    Oct 2010
    Location
    England
    Search Comp PM
    Originally Posted by 4candles View Post
    There are two audio streams in the file - the first should be approx 128kbps AAC-LC (the main audio) and the second is approx 64kbps AAC-HE (audio description). Compatible Freeview HD receivers decode and mix both audio streams when the user enables audio description.
    Hmm, mediainfo is reporting differently:

    Code:
    Audio #1
    ID                               : 6602 (0x19CA)
    Menu ID                          : 17540 (0x4484)
    Format                           : MPEG Audio
    Format version                   : Version 1
    Format profile                   : Layer 1
    Mode extension                   : Intensity Stereo + MS Stereo
    Emphasis                         : CCITT
    Duration                         : 30s 442ms
    Bit rate mode                    : Constant
    Bit rate                         : 416 Kbps
    Channel(s)                       : 1 channel
    Sampling rate                    : 44.1 KHz
    Video delay                      : -882ms
    Stream size                      : 1.51 MiB (8%)
    Language                         : English
    
    Audio #2
    ID                               : 6606 (0x19CE)
    Menu ID                          : 17540 (0x4484)
    Format                           : AAC
    Format/Info                      : Advanced Audio Codec
    Format profile                   : High efficiency AAC@L2
    Duration                         : 30s 37ms
    Video delay                      : -314ms
    Language                         : English
    Language, more info              : Visual impaired commentary
    Both mplayer and VLC only produce sound with the first audio track selected. Whenever I've heard narrative audio it has had the same audio mix as the main channel + a narrator. I haven't heard about Freeview receivers mixing audio streams before. Do yo have any links about this?

    I've only worked with .ts streams from Freesat, and recent versions of ffmpeg have dealt with the files - but I've always re-encoded the streams rather than remux them.

    I'll see if I can demux that second audio track.

    EDIT: Just to confirm that ffmpeg is reporting both tracks as aac_latm. Looks like mediainfo is wrong.
    Last edited by intracube; 17th May 2012 at 08:21.
    Quote Quote  
  11. Originally Posted by intracube View Post
    Both mplayer and VLC only produce sound with the first audio track selected. Whenever I've heard narrative audio it has had the same audio mix as the main channel + a narrator. I haven't heard about Freeview receivers mixing audio streams before. Do yo have any links about this?

    I've only worked with .ts streams from Freesat, and recent versions of ffmpeg have dealt with the files - but I've always re-encoded the streams rather than remux them.

    I'll see if I can demux that second audio track.

    EDIT: Just to confirm that ffmpeg is reporting both tracks as aac_latm. Looks like mediainfo is wrong.
    Some info on Freeview HD is here - http://www.astra2d.com/freeviewhd.html

    I too have worked with Freesat .ts files for a long time. As an aside, I found that up to about about July 2010, recordings from BBC HD on satellite would play back unmodified on my PS3. However, around that time, something changed, and all my recordings since then don't play back on my PS3. Do you have a PS3, and if so, did you find this? I still haven't determined the reason, but I think running the files through tsmuxer fixes them.


    Going back to the Freeview HD recordings, I've now had some success, using some of Selur's last advice:

    Code:
    wine eac3to.exe -demux input.ts
    wine LOAS_LATM_to_ADTS.exe audio_from_eac3to.aac audio.aac 
    ffmpeg -i input.ts -an -vcodec copy "output.mp4"
    MP4Box -add audio.aac output.mp4
    The resulting output.mp4 plays fine on my PS3 (streamed from medatomb).

    I haven't resolved the audio sync issue yet (eac2to reports the delay, but the delay= option in mp4box doesn't seem to work with the PS3), but at least I know I can get the PS3 to play this combination of codecs. The most reliable way to do this is probably to trim the audio to remove Xms of audio (assuming the delay is "audio-first") - time for me to read about LATM/ADTS formats...

    I'll also try and work out what's different with this and the other ways I have tried - my guess is that it's because ffmpeg is creating the mp4 instead of MP4Box. IIUC, MP4Box is just adding a second track to the existing file, and leaves a lot of the metadata the way ffmpeg created it.

    I'm still interested in seeing if I can create a PS3 compatible transport stream though - I would like to be able to write a server app that streams these channels live to my PS3.

    Thanks for everyone's help so far.

    EDIT: This MP4 file is also playing fine on my iPhone 4S (which I believe has the same video capabilities as the iPad 2/3). My next problem is creating compatible transport streams, so I can attempt to implement live streaming to these devices...
    Last edited by 4candles; 17th May 2012 at 09:33.
    Quote Quote  
  12. Member yoda313's Avatar
    Join Date
    Jun 2004
    Location
    The Animus
    Search Comp PM
    Originally Posted by 4candles
    I'm still interested in seeing if I can create a PS3 compatible transport stream though - I would like to be able to write a server app that streams these channels live to my PS3.
    Have you checked out playon, tversity or ps3mediaserver yet? I'm not sure if they can work with tv streaming off a box but they have the streaming function to talk to the ps3 built in.

    Also you might fiddle around with the streaming ability of vlc media player.

    Edit - also I see you are in the UK. I know there is a tv addon device that was made for ps3 but was never released in the US. You might look into it - I think it was a pvr device. That might have what you are looking for. Though I'm not sure if that was only available in Japan or not. I don't remember what it was called though.
    Donatello - The Shredder? Michelangelo - Maybe all that hardware is for making coleslaw?
    Quote Quote  
  13. @yoda313,

    Thanks for the tips, but I haven't found any existing tools which would stream live DVB broadcasts in a satisfactory way. I've written my own tool (which I should get round to releasing at some point...) which is working to stream to the PS3. Currently it requires a separate DLNA content directory server (I'm using pshare) but the actual streaming to the PS3 is working fine (it's just transmitting the original transport stream over http, with a re-written PAT to only include the video and main audio PIDs). I've started work on incorporating a DLNA content directory server to it, which is working with VLC, but doesn't work the PS3 yet.

    The TV addon device is called PlayTV, but that requires it to be connected to the PS3, and only works with standard definition DVB-T. I want a server-side solution, and support for DVB-T/T2 and DVB-S/S2 (and both SD and HD channels).
    Quote Quote  
  14. Member
    Join Date
    Oct 2010
    Location
    England
    Search Comp PM
    Originally Posted by 4candles View Post
    As an aside, I found that up to about about July 2010, recordings from BBC HD on satellite would play back unmodified on my PS3. However, around that time, something changed, and all my recordings since then don't play back on my PS3. Do you have a PS3, and if so, did you find this? I still haven't determined the reason, but I think running the files through tsmuxer fixes them.
    I haven't got a PS3. Not sure what the BBC would have changed to break PS3 playback. I think MBAFF was introduced in 2010, but your recent sample file also uses it - and you say the video plays back on the PS3.

    I'm still interested in seeing if I can create a PS3 compatible transport stream though - I would like to be able to write a server app that streams these channels live to my PS3.
    What about this:
    Code:
    ffmpeg -i bbc1hd-freeviewhd-example.ts -vcodec copy -acodec aac -strict -2 converted.ts
    *an ffmpeg error has to be suppressed with "-strict -2" - aac encoding is stated as being "experimental". I don't know how good the audio quality will be after the conversion, but VLC plays the file and the audio is synced.
    Quote Quote  
  15. Member yoda313's Avatar
    Join Date
    Jun 2004
    Location
    The Animus
    Search Comp PM
    Originally Posted by 4candles
    The TV addon device is called PlayTV, but that requires it to be connected to the PS3, and only works with standard definition DVB-T. I want a server-side solution
    Thanks for letting me know what it was called. Sorry it won't work for ya.

    Good luck.
    Donatello - The Shredder? Michelangelo - Maybe all that hardware is for making coleslaw?
    Quote Quote  
  16. Originally Posted by intracube View Post
    I'm still interested in seeing if I can create a PS3 compatible transport stream though - I would like to be able to write a server app that streams these channels live to my PS3.
    What about this:
    Code:
    ffmpeg -i bbc1hd-freeviewhd-example.ts -vcodec copy -acodec aac -strict -2 converted.ts
    *an ffmpeg error has to be suppressed with "-strict -2" - aac encoding is stated as being "experimental". I don't know how good the audio quality will be after the conversion, but VLC plays the file and the audio is synced.
    That doesn't seem to make any difference - the PS3 gives a "corrupted data" message for any transport stream muxed by ffmpeg. The PS3 accepts TS files muxed by tsmuxer, but ignores the audio stream.

    I've also discovered the "-absf aac_adtstoasc" option to ffmpeg when creating an MP4 file. IIUC, this is required to write the codec info atom in the MP4 file. With this option, the PS3 will accept MP4 files created by ffmpeg. I still need to convert the audio from LATM to ADTS outside of ffmpeg, but it shows that ffmpeg's MP4 support is working for the PS3.

    I also tried just using vlc to create both ts and mp4 directly from the original recording. The MP4 file fails on both PS3 and iPhone, presumably because it is created with the audio stream as "self-synchronised", and the video stream synced to the audio stream. (every other method does it the other way around). The TS file plays on the PS3, but the PS3 fails to detect the audio stream.

    So to summarise:

    PS3 TS - works with tsmuxer or vlc, but no audio stream detected.
    PS3 MP4 - works with ffmpeg if using -absf aac_adtstoasc and ADTS formatted AAC audio.

    For the iPhone/iPad (MP4), it seems my earlier report of success was premature. Audio is being played fine, but the video either freezing immediately (screen covered with green blocks) if I use ffmpeg for the muxing, or is freezing after about 30 seconds of playback (if I mux the video with ffmpeg, then add the audio with MP4Box).

    For the benefit of anyone reading this in the future, the closest combination I have found to play back Freeview HD recordings on the PS3 is:

    Code:
    vlc -I dummy input.ts --sout '#std{access=file,mux=ts,dst="output.ts"}' vlc://quit
    ffmpeg -i output.ts -absf aac_adtstoasc -acodec copy -vcodec copy output.mp4
    However, this has problems with A/V sync. The output.ts file is correctly synced, but has (in my test file) about 1s of extra audio at the beginning of the stream (this is in the input file too). The problem is that ffmpeg doesn't account for this correctly.

    So still more investigation to do..
    Quote Quote  
  17. I've been investigating the A/V sync with vlc.

    It seems that VLC is trimming the video stream before it remuxes it - presumably to skip any partial GOPs at the start of the recording. However, it doesn't seem to drop any audio packets to match the dropped video, or to attempt to sync with the start of the video stream. Hence there is an even longer difference at the start of these files than in the original recording.

    I've adapted an existing ts manipulation tool I've written to remove all audio packets at the start of the file produced by VLC where the PTS is before the first PTS in the video stream. In my tests, this can drop up to a second (or more) of audio, and the resulting A/V first PTS difference is no more than about 10-20ms.

    If I then run this through ffmpeg to convert VLC's ts to mp4, then the stream appears to be (more or less) in sync. I need to do more tests with different material to convince myself it's perfect though.
    Quote Quote  
  18. Member
    Join Date
    Oct 2010
    Location
    England
    Search Comp PM
    Originally Posted by 4candles View Post
    That doesn't seem to make any difference - the PS3 gives a "corrupted data" message for any transport stream muxed by ffmpeg. The PS3 accepts TS files muxed by tsmuxer, but ignores the audio stream.
    I've said this in the past, but it's a pity there isn't a media parser/validator that checks audio/video/transport streams against the official specs. It would make it much easier to point the finger when incompatibility issues arise.

    However, this has problems with A/V sync. The output.ts file is correctly synced, but has (in my test file) about 1s of extra audio at the beginning of the stream (this is in the input file too). The problem is that ffmpeg doesn't account for this correctly.
    Yes it's a shame that ffmpeg and other tools often handle this badly and don't have an option to normalize/align the a/v streams. Of course padding the streams with black or silence would be preferable to discarding - but I guess that would require encoding capabilities so couldn't easily be done as 'post-processing'.

    Does the PS3 only play ffmpeg generated MP4 streams if the aac has been formatted as adts?

    You haven't mentioned mencoder yet. Might be worth seeing if it can generate compatible streams.

    I wish I could be more help, but quite a lot of this is beyond my understanding
    Quote Quote  
  19. intracube,

    I've only been able to create MP4 files containing ADTS audio streams, so I don't know if the PS3 (or even the MP4 specs) support LATM.

    I had a quick play with mencoder, and IIUC, it doesn't have its own mpegts muxer, but uses ffmpeg's. So I would suspect the same results.

    My current thinking is that I will write a tool to convert LATM audio streams to ADTS "in-place" in the original MPEG-2 TS file. After conversion, ADTS is slightly smaller than LATM, which means I should be able to modify the contents of the audio transport stream packets without actually demuxing/remuxing the original recording. So this would give me my original TS file, but with ADTS audio instead of LATM.

    ffmpeg can then be given that file directly, which may turn out to be me more reliable in terms of A/V sync than passing it through vlc first.
    Quote Quote  
  20. would be nice to have a stand alone open source command line tool to convert latm to adts packed aac streams,.. (open source, so one can compile it for linux/mac/windows ), so if you write one, please share with the community.

    Cu Selur
    Quote Quote  
  21. Originally Posted by Selur View Post
    would be nice to have a stand alone open source command line tool to convert latm to adts packed aac streams,.. (open source, so one can compile it for linux/mac/windows ), so if you write one, please share with the community.
    I've made some progress on this, and have something working. It takes a transport stream containing a capture of a DVB broadcast with LATM audio as input (on stdin), and outputs (on stdout) the same transport stream but with the AAC converted from LATM packing to ADTS packing.

    It works by manipulating the contents of the transport stream packets directly - so it keeps the original timing etc from the source transport stream. It doesn't demux/remux the stream.

    In my test streams at least, the LATM header is about 11 bytes, compared to 7 bytes for a standard ADTS header. The actual AAC payload is identical, although in the LATM version it is not byte-aligned. So the AAC data has to be shifted by a few bits to align it in the ADTS version.

    My tool also changes the stream type of the audio in the PMT from 0x11 (AAC-in-LATM) to 0x0f (AAC-in-ADTS).

    Everything is auto-detected - there are no command-line options currently. The main requirement on the input stream is that it contains PAT packets (PID 0) and exactly one stream of PMT packets (and the associated elementary streams for the service described in that PMT packet). The PAT can refer to multiple programs (common with DVB recordings), as long as only one actually exists in the file. As a bonus my tool strips out references in the PAT to all services apart from the one actually contained in the file. This should ensure maximum compatibility with other tools.

    After being run through this tool, ffmpeg will convert my recordings to mp4 directly, and these mp4 files play with perfect A/V sync in VLC. However, my problem isn't solved as these files still exhibit unsynced audio when playing on my PS3. Seems like I may need to return to my idea of dropping audio packets at the start of the recording.

    Like various other DVB-related tools I've written, it's GPL'd. I still need to do more testing and bug-fixing before I release it, and I hope to get time to do that this weekend.
    Quote Quote  
  22. In case anyone is interested, my WDTV Live played the bbc ts file from post #6 properly. The second audio channel was silent though.
    Quote Quote  
  23. Originally Posted by jagabo View Post
    In case anyone is interested, my WDTV Live played the bbc ts file from post #6 properly. The second audio channel was silent though.
    Thanks for letting me know - useful to be reminded that instead of fighting with my PS3 I may be better off just buying something that works...

    Second audio channel being silent probably just means that there was no audio description for that broadcast (or during those 30 seconds I recorded).

    I've now opened a support ticket with Sony asking if the PS3 does actually support transport streams containing AAC audio and will wait to see if/how they respond.
    Quote Quote  
  24. Am experiencing similar "challenges" using Mythbuntu 12.04 PCTV T2 Tuner and using Mythtv's built in UpnP Server to try to stream HD Recordings to PS3.

    Similar to WDTV Live experience above, I've found that the Sumvision Cyclone Live Media Player Adaptor Version 2 1080p can successfully play/stream Freeview HD Recrodings directly from MythTV upnp Server without modification to the recording files. Cost of mine was ~45 pounds from Ebuyer in the UK and quite satisfied with this as a low cost option to stream Freeview HD Recordings from MythTV without need for LATM conversion/stripping.

    I would still like to solve the PS3 Streaming scenario and would be interested to learn more of 4candle's work to date in this area. Can we see your work on the web somewhere?

    I've been tearing my hair out with permutations of vlc and ffmpeg but it seems that you've made real progress with C Complier without major reconstruction/processing of transport streams.

    I've been considering a similar approach to strip out commercials using AAC 2.0 / 5.1 transitions in 5.1 recordings and am wondering if this can be done quite coarsely, i.e. simply dropping A/V packets, during the 2.0 commercial breaks.
    Quote Quote  
  25. Reading/posting earlier gave me motivation to start experimenting again ......

    On my Ubuntu 12.04 / Mythtv Server, here's a vlc-nox command line that will transcode audio in a Freview HD recording to MP2A and the resultant TS file can be streamed to a PS3. Audio seems to be in sync.

    vlc -I dummy Input.mpg --sout '#transcode{acodec=mp2a,ab=192,channels=2,samplera te=48000}:duplicate{dst=std{access=file,mux=ts,dst =Output.ts}' vlc://quit

    I think this should also work with acodec=a52 or ac3 however these encoders don't seem to be included in the standard install of vlc-nox. I think mp2a at 192kbs is sufficient for 2 channel audio.
    Quote Quote  
  26. Originally Posted by jscot View Post
    I would still like to solve the PS3 Streaming scenario and would be interested to learn more of 4candle's work to date in this area. Can we see your work on the web somewhere?

    I've been tearing my hair out with permutations of vlc and ffmpeg but it seems that you've made real progress with C Complier without major reconstruction/processing of transport streams.

    I've been considering a similar approach to strip out commercials using AAC 2.0 / 5.1 transitions in 5.1 recordings and am wondering if this can be done quite coarsely, i.e. simply dropping A/V packets, during the 2.0 commercial breaks.
    I haven't published anything yet, and due to a sample I downloaded from this thread:

    https://forum.videohelp.com/threads/346513

    I've decided to rewrite the LATM to ADTS conversion to use a different approach. The problem with that sample is that there are multiple LATM frames in each PES packet. UK Freeview HD streams only have one LATM frame per PES packet, and my program wrongly assumed that would always be the case. This new approach will make my code cleaner though, so I'm happy I saw that sample when I did. The outcome will be the same (changing the audio data inside the transport stream packets without remuxing), it's just how it works internally is changing.

    I'm part of the way through this rewrite, and once my program is working with both that sample and Freeview HD, I'll release the first version. I can't promise when that will be though, as I'm only able to work on this in my spare time (family and paid work come first).

    I started writing this tool just to perform the LATM to ADTS conversion, but quickly realised it would be useful to incorporate other TS processing features into it. The main features I have in mind are:

    • Roughly cutting the recording based on the PTS timestamps (these are displayed in mplayer). I have a program that does this already but I never released it pubically. I intend to merge that code into this new tool.
    • Synchronising the streams - dropping video packets at the start of the recording to start on a GOP and to drop audio packets to match. The intention is that if you use a third-party tool to then demux the streams and repack, no audio offset will be required to maintain sync (I'm mainly thinking about ffmpeg's mp4 demuxer, which apart from AV sync appears to work well).
    • Similar processing at the end of a stream (but that's a lower priority, as it doesn't matter by that stage...)
    I'm interested in your idea to remove commercials based on the change of audio format - this should be relatively straightforward to do once all the other features are done. Detecting change of audio format is on my to-do list anyway, so I will be adding that relatively soon (and displaying the timestamps of where the changes happen).


    I'm not sure about dropping packets at that point - I think the first approach I would take would be to split the file based on audio format. So you would get a new file every time the audio format changed. If you wanted, you could then "cat" the program parts together and see how the various players dealt with it.
    Quote Quote  
  27. Originally Posted by jscot View Post
    Reading/posting earlier gave me motivation to start experimenting again ......

    On my Ubuntu 12.04 / Mythtv Server, here's a vlc-nox command line that will transcode audio in a Freview HD recording to MP2A and the resultant TS file can be streamed to a PS3. Audio seems to be in sync.

    vlc -I dummy Input.mpg --sout '#transcode{acodec=mp2a,ab=192,channels=2,samplera te=48000}:duplicate{dst=std{access=file,mux=ts,dst =Output.ts}' vlc://quit

    I think this should also work with acodec=a52 or ac3 however these encoders don't seem to be included in the standard install of vlc-nox. I think mp2a at 192kbs is sufficient for 2 channel audio.
    Thanks for that - that could be useful until I find a way to keep the original AAC audio. For MP2, I would use 256kbps though - that's the bitrate the BBC and others use for their standard definition channels. I can't guarantee you would hear a difference, but an extra 64kbps won't hurt...

    I see you've called the file "input.mpg" in your example - does this mean that Myth records program streams, instead of the original transport streams? (the mpg extension is usually used for program streams). Or am I reading too much into your example?
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!