-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dirk Meyer wrote: | Hi, | | Andrew Jeffery wrote: |> The first was with mplayer and it's time detection problems in |> MPEG-TS streams - commercial detection wasn't working as mplayer |> seemed to randomly get the starting time position in the video wrong |> (i.e. hit play on a video and mplayer reckoned it was 13 hours or so |> in - comfortably missing all the edl time values) | | Mplayer (and Xine) have the big problem that they can not seek | correctly on MPEG-TS files. Unlike AVI a TS has no Index. Xine for | example checks the bitrate at the beginning and calculates everything | based on that bitrate. As a result while watching a recording in | Freevo 2.0 the elapsed time information on my LCD goes up one second | every two seconds. Mplayer does not have that bug, but seeking 10 | seconds can result in a 30 second seek or even more. | | THE ONLY way for correct TS seeking is looking at the timestamp in the | TS frame. That is how kaa.metadata detects the length of the file: | read the first and the last timestamp.
Hmm... from what I understand from reading TS articles on wikipedia, http://www.coolstf.com/mpeg/index.html and http://books.google.com.au/books?id=yWrWqcghf3AC&pg=PA27&lpg=PA27&dq=pcr+reset&source=web&ots=GdNfIhnlMS&sig=lu5WAauT7zTFOllLPfIhxK-f0gE&hl=en#PPA27,M1 is that the timestamp (PTS) in each frame is relative to the program clock reference (PCR), which can be reset. Is that right? If it is do the resets get recorded? Is that an option for fixing the problem (probably a more relevant question for the mplayer/xine devs... in fact this whole issue probably is ;) )? What I was going to work on was automagically re-encoding programs (create a TV_RECORD_REENCODE config var or something) after they've finished recording (less space required and (hopefully) working commercial detection), but came up against the encoding server failing because the time wasn't reported properly. The first traceback in the first email posted isn't relevant using svn head, the massive length problem seems to have been fixed somewhere. I'm thinking the 'None' issue could be fixed with something like: Index: encodingcore.py =================================================================== - --- encodingcore.py (revision 10613) +++ encodingcore.py (working copy) @@ -318,7 +318,7 @@ ~ if config.DEBUG >= 2: ~ for f in dir(data): ~ _debug_('%s: %s' % (f, eval('data["%s"]' % f)), 2) - - if data.has_key('length'): + if data.has_key('length') and data['length'] is not None: ~ self.length = data['length'] ~ _debug_('Video length is %s' % self.length) ~ else: i.e. if length is 'None' letting it fall into the else block as it might as well have not been specified. | | Maybe the whole commercial detection based on mplayer and edl values | is wrong. Hans-Juergen (Cc) started porting noad (the VDR commercial | detection) to something more generic. IMHO the best encoding server | would use gstreamer and a gstreamer commercial detection. Maybe Zaheer | (also Cc) knows if something like this is already work in progress. | |> an hour long episode of Kitchen Nightmares USA was supposedly 2973 |> minutes. | | What does mminfo say? mminfo says: [EMAIL PROTECTED] /var/tv/recordings $ mminfo 02-14_21\:30_Kitchen_Nightmares_Usa.ts kaa media metadata info ERROR mpeg(765): bad TS 02-14_21:30_Kitchen_Nightmares_Usa.ts | type: MPEG-TS | media: MEDIA_AV | mime: video/mpeg | interlaced: True +-- Video Track #1 | | media: MEDIA_VIDEO | | bitrate: 15000000 | | codec: MPEG-2 Video | | width: 720 | | height: 576 | | fps: 25 | | aspect: 1.77777777778 | | fourcc: MP2V | | id: 512 +-- Audio Track #1 | | media: MEDIA_AUDIO | | codec: MPEG-2 Audio | | fourcc: MP2A | | id: 650 Length is missing :( where is freevo getting the 2973 from? [EMAIL PROTECTED] /var/tv/recordings $ ~/freevo-test/bin/mminfo 02-14_21\:30_Kitchen_Nightmares_Usa.ts ERROR mpeg(765): bad TS 02-14_21:30_Kitchen_Nightmares_Usa.ts | type: MPEG-TS | media: MEDIA_AV | mime: video/mpeg | interlaced: True +-- Video Track #1 | | media: MEDIA_VIDEO | | bitrate: 15000000 | | codec: MPEG-2 Video | | width: 720 | | height: 576 | | fps: 25 | | aspect: 1.77777777778 | | fourcc: MP2V | | id: 512 +-- Audio Track #1 | | media: MEDIA_AUDIO | | codec: MPEG-2 Audio | | fourcc: MP2A | | id: 650 Nothing changed in the newer version, freevo (svn head) is reporting the length as 0 now :s And midentify at Duncan's suggestion: [EMAIL PROTECTED] /var/tv/recordings $ ~/mplayer-svn/TOOLS/midentify 02-14_21\:30_Kitchen_Nightmares_Usa.ts ID_FILENAME=02-14_21:30_Kitchen_Nightmares_Usa.ts ID_DEMUXER=mpegts ID_VIDEO_FORMAT=0x10000002 ID_VIDEO_BITRATE=15000000 ID_VIDEO_WIDTH=720 ID_VIDEO_HEIGHT=576 ID_VIDEO_FPS=25.000 ID_VIDEO_ASPECT=0.0000 ID_AUDIO_FORMAT=80 ID_AUDIO_BITRATE=0 ID_AUDIO_RATE=0 ID_AUDIO_NCH=0 ID_LENGTH=1143.82 ID_VIDEO_CODEC=mpegpes ID_AUDIO_BITRATE=256000 ID_AUDIO_RATE=48000 ID_AUDIO_NCH=2 ID_AUDIO_CODEC=mp3 Length is a bit strange... Andrew | | | Dischi | - -- "Encouraging innovation by restricting the spread & use of information seems highly counterintuitive to me." - Slashdot comment -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIADMa/5R+ugbygqQRAkPuAJ9z3D0EbMfe2Zn1s5TWu4qHxSAeGACdGEbC JDJEmE8ACAkVnHjBldAupTU= =g9On -----END PGP SIGNATURE----- ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
